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

Update: The Docker documentation was amended by moby/buildkit#5381 and no longer shows contradictory information.

Podman buildah should be updated to support argument inheritance in the same way as Docker buildkit.

Interested in opening a PR?

Interested, yes, but I'm not familiar with the Podman source code and have no idea where to start.

The place to start would be Buildah not Podman, Podman vendors in buildah to do all of its container image building.

Buildah is a smaller code base.

As far as I can see, arguments are resolved in https://github.com/openshift/imagebuilder/blob/master/builder.go#L290 per stage.

As buildah seems to defer to openshift/imagebuilder to do all the heavy lifting, should I open an issue (or possibly PR) on this repository instead?

I expect the fix would eventually be made there, yes.

This looks much more complicated after all. I suppose it would be better to not try to resolve arguments during initial parsing, but record resolved arguments on the fly and them make them available to dependent build stages.

1. While building each stage, record processed arguments in a map
2. At the end of the build, keep the final argument map
3. Share this map with child stages before their build starts

This requires that child stages must wait until their parent finishes, but from what I can see in https://github.com/containers/buildah/blob/main/imagebuildah/executor.go#L908 , they would all run in parallel, and it's not obvious to me how dependencies between stages are guaranteed? Could you help explain how this works?

Ok, so... processed arguments are already recorded in Stage.Builder.Args.

Proposal:

1. Add the field Executor.argResult of type map[string]map[string]string
2. At the end of a stage build, copy Stage.Builder.Args to Executor.argResult[stageName] (with locking)
3. Add an additional return value to Executor.waitForStage of type map[string]string, which is copied from Executor.argResult[stageName] (with locking)
4. At the beginning of a stage build, add the returned map from waitForStage to Stage.Builder.Args
5. Other places where waitForStage is used can just discard the args

Edit: I submitted a PR based on this idea from my personal GH account. It's completely untested and needs some finetuning.