feat(build): add --mount option

[aeijdenberg]

This allows adding an ephemeral mount to all RUN commands in a Containerfile during a build.

What type of PR is this?

/kind feature

What this PR does / why we need it:

This adds a --mount option to build which has the effect of adding this mount to each RUN command in a Containerfile before executing. For example:

buildah build --mount type=secret,id=mysecret ...

and a Containerfile entry of:

RUN cat /run/secrets/mysecret

Has the same effect as:

RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

This is useful in conjunction with #6285 for building existing Containerfile's with different environmental considerations (such as SSL_CERT_FILE data etc) without needing to modify the existing Containerfile's or causing changes to the produced images.

How to verify it

bats test added.

FOO=world ./bin/buildah build \
      --secret id=mysecret,env=FOO \
      --mount type=secret,id=mysecret,dst=/bar,required \
      -f <(printf 'FROM busybox\nRUN echo "hello $(cat /bar) welcome"')

Prints:

hello world welcome

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

There is an existing field TransientMounts in BuildOptions that had comment suggesting it would do exactly as described by this PR, however it does not quite operate as described, rather it expects each argument to be a src:dest volume mount (I suspect it predates other types of mounts):

buildah/define/build.go

Lines 148 to 150 in db61e10

	// TransientMounts is a list of unparsed mounts that will be provided to
	// RUN instructions.
	TransientMounts []string

Since that field was part of the public API, I didn't change it's behaviour in this PR, but I did adjust the comment and added a new fields for other mounts.

Does this PR introduce a user-facing change?

This adds a `--mount` option to `build` which has the effect of adding this mount to each `RUN` command in a Containerfile before executing. For example:

`buildah build --mount type=secret,id=mysecret ...`

and a Containerfile entry of:

`RUN cat /run/secrets/mysecret`

Has the same effect as:

`RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret`

[aeijdenberg]

I found #5987 today, who look to be trying solve a similar case to me. I'd like to set some transient related env vars and file mounts during the build phase that shouldn't affect the final image.

For example, this options allow me to run:

buildah build \
        --secret id=MAVEN_SETTINGS_FILE,type=file,src=/path/to/host/mvn.settings \
        --run-mount type=secret,id=MAVEN_SETTINGS_FILE,target=/usr/share/maven/conf/settings.xml,required \
...

(and related PR #6285 to expose in an env variable to the build process)

[aeijdenberg]

If interested, here's some context on how I'm using this - the intent to is make buildah work really well with HTTP proxies such that all assets pulled by buildah and RUN, ADD instructions are pulled through, ideally with no changes to the Containerfile, ie make it work transparently, including when TLS is inspected. The idea being that assets needed for a build can be saved and put-aside, then re-served later to support a future build.

Here's a full writeup of the tool I'm working on and info about the patches added to buildah to allow it to work in this context (all of which have PRs open here):

https://github.com/continusec/htvend/
https://github.com/continusec/htvend/blob/main/oci-image-building.md#no-method-to-pass-ssl_cert_file-to-run-instructions-in-dockerfile

[github-actions]

A friendly reminder that this PR had no activity for 30 days.

[aeijdenberg]

Rebased to fix merge conflict.

[nalind]

Generally looks fine. Flags, even when they're specific to RUN, don't tend to have a "run-" prefix for buildah build - they tend to just look like the do for buildah run. This currently conflicts with that convention.
There's probably a missing assignment to the flagCompletion map in the pkg/cli.GetBudFlagsCompletions() function for this new flag.

[aeijdenberg]

Thanks for the feedback.

Generally looks fine. Flags, even when they're specific to RUN, don't tend to have a "run-" prefix for buildah build - they tend to just look like the do for buildah run. This currently conflicts with that convention.

I've renamed to --mount which matches the corresponding existing option for the buildah run.

There's probably a missing assignment to the flagCompletion map in the pkg/cli.GetBudFlagsCompletions() function for this new flag.

Added.

[nalind]

LGTM

[nalind]

Ugh, I created merge conflicts with #6442. If I can trouble you to rebase one more time, I'll go ahead and merge this.

[aeijdenberg]

Ugh, I created merge conflicts with #6442. If I can trouble you to rebase one more time, I'll go ahead and merge this.

Done, and thanks for reviewing.

[nalind]

/lgtm
Thanks!

[openshift-ci]

New changes are detected. LGTM label has been removed.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aeijdenberg
Once this PR has been reviewed and has the lgtm label, please ask for approval from nalind. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[aeijdenberg]

Rebased to fix merge conflict.