SHIP-22: add deprecation notice for implicit tekton workspace emptydir volumes

[gabemontero]

Changes

Announce the deprecation of the implicit use of tekton workspace emptydir volumes for the git repo cited in the build source reference.

Per https://github.com/shipwright-io/community/blob/main/ships/0022-build-strategy-volumes.md#removing-a-deprecated-feature-if-necessary

Per our recent convention, @adambkaplan and I are of the understanding that we announce / "deprecate" in the current release (the upcoming v0.7.0), and then remove / replace with the full implementation of https://github.com/shipwright-io/community/blob/main/ships/0022-build-strategy-volumes.md in v0.8.0

/assign @adambkaplan
@SaschaSchwarze0 @sbose78 @imjasonh FYI (please assign yourselves as you see fit)

@adambkaplan - as you can tell from the PR, there was not much present to latch onto to announce the deprecation for my assignment here. In fact, I added to the API godoc to "reveal" the implicit use of Tekton's emptydir volume to volume mount mapping to lend context to the "deprecation" notice that followed. If there are spots where this implicit use of emptyDir is discussed in documentation that I have missed that you are aware of, please advise. I similarly added a new section in the build strategy markdown to first lend some context, then announce the deprecation.

/kind feature

Submitter Checklist

• [n/a ] Includes tests if functionality changed/was added
• [ /] Includes docs if changes are user-facing
• [ /] Set a kind label on this PR
• [ /] Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Shipwright's implicit association of an emptydir volume to any BuildStep/Container VolumeSource that needs an associated Volume is marked as deprecated in the upcoming release, with the intent of replacing it with an implementation of SHIP-22 in the following release.  If your build strategies (both Clustered and Namespaced) leverage this behavior, please start planning to employ the alternative approach described in https://github.com/shipwright-io/community/blob/main/ships/0022-build-strategy-volumes.md

[gabemontero]

Error: error processing import paths in "deploy/500-controller.yaml": error resolving image references: GET https://registry.access.redhat.com/v2/ubi8/ubi-minimal/blobs/sha256:e7685639f55280ffe8da3724cb1d342091a1ceea79af5eb91a07ce97cd32f221: UNAVAILABLE: Server error encountered while handling request
2021/11/09 19:46:29 error during command execution:error processing import paths in "deploy/500-controller.yaml": error resolving image references: GET https://registry.access.redhat.com/v2/ubi8/ubi-minimal/blobs/sha256:e7685639f55280ffe8da3724cb1d342091a1ceea79af5eb91a07ce97cd32f221: UNAVAILABLE: Server error encountered while handling request

assuming that is a registry flake

[SaschaSchwarze0]

/reject

SHIP-22 is covering a different deprecation: a build strategy author today can define a volumeMount for any step which results in an emptyDir volume being implicitly added to the TaskRun/Pod. For example: https://github.com/shipwright-io/build/blob/main/samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml#L17-L19

The source is handled completely by shipwright. The build strategy author should not be required to define an emptyDir volume for it.

[gabemontero]

/reject

SHIP-22 is covering a different deprecation: a build strategy author today can define a volumeMount for any step which results in an emptyDir volume being implicitly added to the TaskRun/Pod. For example: https://github.com/shipwright-io/build/blob/main/samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml#L17-L19

The source is handled completely by shipwright. The build strategy author should not be required to define an emptyDir volume for it.

Ahh .... I had mentioned the code links in question where my TODO's currently are with @adambkaplan as part of one of our internal RH meetings where we plan our next assignments, and things were "OK'ed", but looks like something got lost in translation.

Perhaps my elaborations in this PR's description reflected my degree of uncertainty with all this :-)

thanks @SaschaSchwarze0 .... I'll circle back to your reference link and go from there.

@adambkaplan - ^^ ..... I imagine @SaschaSchwarze0 is correct and we had a disconnect in planning and addressing my open questions, but of course chime in if you disagree.

[gabemontero]

ok I'm still trying to get confirmation with @adambkaplan on some details, but in the meantime I've taken a stab at resetting how we announce the deprecation @SaschaSchwarze0

if you get the chance let me know if we are on a better path, as well as any specific suggestions etc. on the new text.

[adambkaplan]

In general I think I'm on the same page with @SaschaSchwarze0. It seems that this implicit behavior isn't well documented, so as a first step this PR should:

1. Document the current behavior
2. Indicate that this behavior will be replaced in a future release.

[adambkaplan]

I would put this towards the bottom of the article, titled "Volumes and Volume Mounts", and keep things simple. Something to the effect of:

## Volumes and VolumeMounts

Build steps can declare a `volumeMount`, which allows data in the provided path to be shared across build steps.
When a `volumeMount` is declared, Shipwright will create an `emptyDir` volume with the corresponding name.
Build steps whose volume mounts share the same name will share the same underlying `emtpyDir` volume.

In a future release, build strategy authors will be able to use other volume types for the volume mounts.
When this feature is introduced, the volume and volume type will need to be explicitly declared.

[gabemontero]

In general I think I'm on the same page with @SaschaSchwarze0.

ok good

It seems that this implicit behavior isn't well documented,

yep that is what I alluded to in my updated description and tried to address

so as a first step this PR should:

1. Document the current behavior

yep I've attempted to do that

2. Indicate that this behavior will be replaced in a future release.

yep attempted to do that too

[gabemontero]

suggestions pulled in and squashed @adambkaplan

[SaschaSchwarze0]

Nice. Looks better now @gabemontero. ;-) May you run the generator to update the OpenAPI spec ?

[adambkaplan]

/approve

Just needs the CRD to be regenerated.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adambkaplan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [adambkaplan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gabemontero]

make generate-crds output pushed as separate commit @SaschaSchwarze0 @adambkaplan thanks

[gabemontero]

/hold

I did the crd update with fedora .... need to redo that with my crd friendly ubuntu

[gabemontero]

/hold cancel

@SaschaSchwarze0 @adambkaplan the crd line break situation has been addressed

PTAL

[gabemontero]

/hold cancel

@SaschaSchwarze0 @adambkaplan the crd line break situation has been addressed

PTAL

wait a sec @SaschaSchwarze0 @adambkaplan .... still having verify issues ... will update when I've sorted them out.

[gabemontero]

ok it is all green now @SaschaSchwarze0 @adambkaplan with no preponderance of line breaks .... PTAL

[SaschaSchwarze0]

/lgtm