Build-273 Volumes support to Build Strategies

[alicerum]

Changes

This PR adds Volumes support to Build Strategies, allowing user to configure volumes and volume mounts used by the future tekton TaskRun object. Allowing eventually to add config maps, secrets and persistent storage to builds and build runs.
Volumes can be overriden by Build and BuildRun objects.

Tests have not been implemented yet, I am working hard to deliver them during the rest of today.

Duscussion topics

In the original SHIP only emptyDir volumes are defined in the BuildStrategy. In this PR any VolumeSource is supported there. In case we want to only implement emptyDirs in the Build Strategies and all the rest in Builds and BuildRins, we could possibly remove emptyDir definition from strategies and rename field as volumeTemplate or something. Clearly stating that this is not a VolumeSource as defined by k8s.

I moved overridable one level higher, to where optional is. Somehow it makes more sense, but I can move it back.

I did not implement the VolumeSource type, because it is not there in the original k8s type, and I figured there are other means of checking the type.

It is claimed in the SHIP that Secret and BuildConfig volume mounts must be read only and BuildRun must fail otherwise. I have never encountered this before, but I implemented it anyways.

Should I fail the BuildRun in case Secret or ConfigMap required by the build does not exist? I have not implemented this yet, and pod hangs indefinitely until resource appears.

Submitter Checklist

• 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

action required: Build Strategies can now define `volumes`, which can be mounted in build steps, and overridden by `Build`s and `BuildRun`s. Build strategies which contain volume mounts in their buid steps must also declare the associated volumes in the strategy spec.

[SaschaSchwarze0]

Thanks for this start @alicerum. I think it uncovers some imprecisions in the ship that I point out in my comments.

[adambkaplan]

I believe I need to update the original proposal and drop the optional and type fields. Some of the API assumed a more "restrictive" approach to persistent volumes, and yet the "Risks and Mitigations" section clearly implies that we'll allow any volume source, including hostPath. Passing through the core k8s VolumeSource object is the correct approach.

The proposal recommends that admins enable the PodSecurity admission plugin. This is default on k8s 1.23. This PR (or a follow-up) should make this recommendation clear to users/admins.

[adambkaplan]

Updated the SHIP here: shipwright-io/community#77

[adambkaplan]

Re-running the e2e test - it looked like all but one e2e test passed. The buildah test failed, looked like it hanged pulling the base image.

[adambkaplan]

@alicerum success! I think the buildah issue was a test flake - if it continues to crop up we'll address in a separate PR.

Please update the Volume mounts section of the Build Strategies doc with the new API, then squash your commits.

[SaschaSchwarze0]

Good progress. :-)

[SaschaSchwarze0]

Three more items, beside the two comments, please also extend the build.md and buildrun.md in the documentation.

[SaschaSchwarze0]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SaschaSchwarze0

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 [SaschaSchwarze0]

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

[coreydaley]

/lgtm