/kind feature

Description

Add an option to buildah build to apply instructions from Containerfiles to an existing Buildah working container. The option could be used like buildah build --use CONTAINER, where CONTAINER is the name of a Buildah working container previously created by buildah from. When a pre-existing working container is used, buildah build shouldn't commit the working container when all instructions were applied.

For single-stage Containerfiles this will cause Buildah to ignore the first and only FROM statement in the Containerfile, and rather use the existing working container instead of creating a new one. Unless the working container isn't modified before and after buildah build, this is virtually the same as buildah build --from (i.e. the new container="$(buildah from fedora)"; buildah build --use "$container"; buildah commit "$container" is the same as buildah build --from fedora). However, it gives the user the freedom to modify the working container both before, and after buildah build; it even allows one to run multiple buildah build after another, without the overhead of additional layers in between.

For multi-stage Containerfiles this new option will cause Buildah to use the existing working container as replacement for the last FROM statement in the Containerfile.

Reasoning

I often use the Containerfile of a project's official image to build my own image. The reason is that I don't want to fiddle around with build and runtime dependencies. I usually trust the project's expertise on these things...

However, I still want to do things in certain ways across a bigger variety of projects. This requires me to not only add some instructions, but to use a custom parent image. Since I don't want to manually merge all upstream changes I try to take the project's Containerfile as-is. Therefore I often build an intermediate image with buildah build --from my_base_image, and then build the final image with this intermediate image as a basis.

This works - most of the time - but has some major disadvantages: First, the buildah build --from approach doesn't work for multi-stage builds, because buildah build --from only overwrites the first FROM statement, not the last. However, the last stage is usually the one that matters: previous stages are often just builder stages. Second, buildah build always commits the container, requiring one to add another layer for additional instructions. The only way to prevent this is to append a second Containerfile to buildah build; however, Containerfiles are inflexible, I prefer using buildah mount, buildah run, et. al.