Map ImagePullPolicy from build strategy step to TaskRun step

[SaschaSchwarze0]

Changes

When defining a build strategy, the author defines which images are to be used. For certain tools, beside immutable image tags for specific versions, there are also nightly or latest-like tags available that are not using latest themselves. In such a a case, Kubernetes sets the image pull policy implicitly to IfNotPresent and does never reload these images so that they get outdated. Examples in our context are:

• moby/buildkit:nightly-rootless
• paketobuildpacks/builder:full

In case of latest, Kubernetes would always contact the registry to check if there is a newer version. To enforce the very same behavior for other tags, the build strategy author needs to specify the Always image pull policy explicitly. But, our code does not pass this flag on to the TaskRun.

Given that this has positive security impact (assuming a newer image is more secure), but some performance cost that the build strategy author explicitly "opts in", I suggest that we pass on this field.

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

Release Notes

Build strategy authors can now specify an `imagePullPolicy` on each step, for example to enforce the `Always` policy also for images that do not use the `latest` tag

[qu1queee]

+1 . Shouldn´t we make this field usage more obvious? either by updating an existing strategy or docs?

[SaschaSchwarze0]

+1 . Shouldn´t we make this field usage more obvious? either by updating an existing strategy or docs?

Good point. Let's set it for those strategy where this is applicable = that use mutable image tags.

[qu1queee]

nice, good one.
/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qu1queee

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

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