inject source via config map / secrets feature

[gabemontero]

Today openshift build v1 API allows for injection of config map content under the source tree of the build container for use during the image build

Do we want to expose a similar policy in build v2?

tekton tasks already allow for mounting of config maps / secret volumes in tasks/taskruns

[sbose78]

Today openshift build v1 API allows for injection of config map content under the source tree

Could you help me with a scenario, please?

[gabemontero]

Today openshift build v1 API allows for injection of config map content under the source tree

Could you help me with a scenario, please?

In this case I think our docs do a sufficient job of capturing this one. See https://docs.openshift.com/container-platform/4.3/builds/creating-build-inputs.html#builds-input-secrets-configmaps_creating-build-inputs

[otaviof]

Interesting use-case, @gabemontero. Putting myself as a final user, it would come handy to share common resources between different builds, therefore, it would act as another point of extensibility, which currently we only offer on BuildStrategy.

Good idea, I think we should pursue it!

[adambkaplan]

/kind feature

This would be useful in two contexts - dovetailing on the discussion in #419:

1. Using ConfigMap and Secrets as content in the image to be built (sources)
2. Using ConfigMap and Secrets as supplemental information used in the build, but is not present in the final image (volumes)

[gabemontero]

@adambkaplan I feel like we can either close this in favor of shipwright-io/community#23 and any items opened as a result of that, or we should cite this issue as something address by that SHIP,

The former feels better but I'm enough on the fence to not hit the close button unilaterally

Thoughts?

[adambkaplan]

There are a few subtle differences:

• SHIP-0022's objective is to let strategy authors define volumes that could be optionally altered by the developer.
• We don't have a SHIP yet that lets developers arbitrarily mount Secrets or ConfigMaps into a Build/BuildRun. That is a logical follow-up to SHIP-0022.

[gabemontero]

There are a few subtle differences:

* SHIP-0022's objective is to let strategy authors define volumes that could be optionally altered by the developer.

* We don't have a SHIP yet that lets developers arbitrarily mount Secrets or ConfigMaps into a Build/BuildRun. That is a logical follow-up to SHIP-0022.

I'm not sure how the existing API or new api proposed in https://github.com/shipwright-io/community/blob/32b3d0f8f802d98a605bc2670fe2094229bdbb98/ships/0022-build-strategy-volumes.md would change based on your 2 points ^^

I have a guess or two perhaps, but instead, would it be feasible to construct yaml tweaks to either existing API or you proposed API to make it clear what you are getting at ?

thanks