Summary
The build subcommand does not currently support the --build-arg flag, which is a standard part of docker compose build. Any project that relies on build-time arguments (e.g. for injecting private registry tokens or license keys into a multi-stage Dockerfile) cannot use container-compose build as a drop-in replacement today.
Current Behavior
Running the following command fails immediately with an unrecognized option error:
container-compose build \
--build-arg BO_NPM_PKG_AUTH_TOKEN=$BO_NPM_PKG_AUTH_TOKEN \
--build-arg FONTAWESOME_PRO_TOKEN=$FONTAWESOME_PRO_TOKEN \
--build-arg SIDEKIQ_KEY=$SIDEKIQ_KEY
Error: Unknown option '--build-arg'
Usage: container-compose <subcommand>
See 'container-compose --help' for more information.
Expected Behavior
Parity with docker compose build, which accepts one or more --build-arg KEY=VALUE pairs and forwards them to the underlying image build process as build-time variables. The equivalent native container build CLI also supports --build-arg, so this should be a straightforward passthrough.
# Should work the same as it does with docker compose
container-compose build \
--build-arg BO_NPM_PKG_AUTH_TOKEN=$BO_NPM_PKG_AUTH_TOKEN \
--build-arg FONTAWESOME_PRO_TOKEN=$FONTAWESOME_PRO_TOKEN \
--build-arg SIDEKIQ_KEY=$SIDEKIQ_KEY
Motivation / Use Case
Build args are essential for projects that need to inject secrets or configuration at image build time without baking them into the image or committing them to source control. Common real-world examples include:
- Private npm registry auth tokens (e.g. GitHub Packages, Artifactory)
- Font Awesome Pro license keys
- Private gem/package credentials (e.g. Sidekiq Pro)
- Any multi-stage Dockerfile that uses ARG to gate access to private dependencies
Without --build-arg support, teams adopting Apple Container via container-compose are blocked from migrating existing Docker-based CI/CD workflows that rely on this flag.
Proposed Implementation
The build command should be updated to:
Accept --build-arg as a repeatable option (i.e. it can be specified multiple times), taking a KEY=VALUE string each time.
For each service being built, pass each provided --build-arg value through to the underlying container build invocation via its own --build-arg flags.
References
docker compose build docs — --build-arg
container build CLI — already supports --build-arg
I appreciate all the work you've done on this project. 🍻
Summary
The build subcommand does not currently support the
--build-argflag, which is a standard part of docker compose build. Any project that relies on build-time arguments (e.g. for injecting private registry tokens or license keys into a multi-stageDockerfile) cannot usecontainer-composebuild as a drop-in replacement today.Current Behavior
Running the following command fails immediately with an unrecognized option error:
Expected Behavior
Parity with docker compose build, which accepts one or more
--build-arg KEY=VALUEpairs and forwards them to the underlying image build process as build-time variables. The equivalent native container build CLI also supports--build-arg, so this should be a straightforward passthrough.Motivation / Use Case
Build args are essential for projects that need to inject secrets or configuration at image build time without baking them into the image or committing them to source control. Common real-world examples include:
Without --build-arg support, teams adopting Apple Container via container-compose are blocked from migrating existing Docker-based CI/CD workflows that rely on this flag.
Proposed Implementation
The build command should be updated to:
Accept --build-arg as a repeatable option (i.e. it can be specified multiple times), taking a KEY=VALUE string each time.
For each service being built, pass each provided --build-arg value through to the underlying container build invocation via its own --build-arg flags.
References
docker compose build docs — --build-arg
container build CLI — already supports --build-arg
I appreciate all the work you've done on this project. 🍻