Make the Docker image self-contained: build the binary inside the Dockerfile

[leighmcculloch]

What problem does your feature solve?

The stellar/stellar-cli Docker image cannot be built from a clean checkout with docker build alone. The stellar binary is built by the GitHub Actions workflow and then copied into the image at build time, so the Dockerfile is not self-contained.

The binary build steps live in .github/workflows/docker.yml:

stellar-cli/.github/workflows/docker.yml

Lines 36 to 40 in 343069b

	- name: Install build dependencies
	run: sudo apt-get update && sudo apt-get install -y --no-install-recommends libudev-dev libdbus-1-dev
	- name: Build binary
	run: cargo build --package stellar-cli --release

The Dockerfile then expects the pre-built binary to already be present in the build context:

stellar-cli/Dockerfile

Lines 9 to 10 in 343069b

	ARG TARGETARCH
	COPY stellar-${TARGETARCH}/stellar /usr/local/bin/stellar

This makes it difficult to test changes to the Dockerfile and the resulting image locally. To build the image a developer has to:

1. Read the GitHub workflow.
2. Replicate the binary build steps in an Ubuntu environment matching the workflow.
3. Place the resulting binary at stellar-${TARGETARCH}/stellar in the build context.
4. Run docker build.

That is fragile and error-prone, and any change to the build process has to be kept in sync across the workflow and the Dockerfile.

What would you like to see?

Move the binary build into the Dockerfile itself as a separate builder stage so the image is self-contained:

• A builder stage based on rust:latest that installs build dependencies (libudev-dev, libdbus-1-dev) and runs cargo build --package stellar-cli --release.
• A final runtime stage that uses COPY --from=builder to pull the resulting stellar binary into place.

The GitHub workflow would then just run docker buildx build (multi-arch) and push, with no separate "build binary" job and no artifact upload/download dance.

Benefits:

• Anyone can build and test the image locally with a single docker build from a clean checkout, no workflow knowledge required.
• The Dockerfile becomes the single source of truth for how the image is built.
• No drift between the workflow's build steps and the Dockerfile's expectations.