inject source via image feature

[gabemontero]

Today openshift build v1 allows for adding files from specified images which are different from the builder image into the build container of use during the image building process.

The image is loaded at build time and the specified files/directories are copied into the context directory of the build process.

The image loading container step in the v1 build process can be replicated in a tekton task step, and file could be copied to the tekton workspace for use in later steps that build and push the image.

[sbose78]

What was the typical use case for this ? Off the top of my head, this looks like something that would have been used for generating lean base images?

[gabemontero]

What was the typical use case for this ? Off the top of my head, this looks like something that would have been used for generating lean base images?

That feels right @sbose78 but to be honest it has been a while.

Revisiting the implementation, we do create a separate volume in the build pod for the extracted image content, and then we copy it to the volume used when actually building the image. So that would lend itself to the new content existing in the same image layer vs. say the multiple layers you can get when using a multi-stage docker build.

It is also possible that our feature pre-dated multistage docker builds.

But let's ask to oracle of openshift builds to keep me honest - @bparees - please comment/correct as you see fit on the motivations on the buildv1 image source build input feature

[bparees]

lean images(not needing you build tooling in the resulting app image) was one use case, another was having an image that contained your dep binaries pre-built/pulled...essentially a cache.

if i recall correctly it also pre-dated docker's multistage builds which can accomplish similar goals (plus it enabled s2i to have a similar capability, since s2i doesn't have access to multistage builds)

[adambkaplan]

/kind feature

These days there are several projects using OCI images to store data, and not running applications. As we have been discussing in #419, we can have multiple source types. Though perhaps this use case is not widely needed.

[qu1queee]

I believe >90% of this can be addressed via the implementation of #419 once we move into that , therefore I would like to close this in the time being. @gabemontero please close if you agree?

[gabemontero]

419 could have been extended to handle this, but at the moment, the merged EP only lists git or http as the possible types.

If the feature/PR opened to implement #419 take on updating the design document to include pulling images, or implements it without updating the design doc, then fine let's close this.

Until then, I say this stays open.