Build Docker image from source via cargo install

[fnando]

What

The Docker image is now built from source via cargo install --git ... --rev "${STELLAR_CLI_REV}" instead of copying a pre-built binary downloaded from a previous workflow job. The build job that produced and uploaded the binary has been removed; the docker job passes STELLAR_CLI_REV (resolved from inputs.ref or the release tag) as a build-arg to docker/build-push-action.

Why

The previously downloaded binary didn't pick up the image's runtime dependencies, so the libdbus error still happened at runtime. Building from source inside the image ensures the binary links against the libraries actually present in the final image.

Known limitations

N/A

[claude]

Claude finished @fnando's task in 2m 18s —— View job

---

Claude Code Review

• Read PR context and changed files
• Review Dockerfile changes
• Review .github/workflows/docker.yml changes
• Post review feedback

---

Summary

The motivation makes sense — linking the binary against the runtime libs it'll actually run with is the right fix for the libdbus regression. But this approach has a few significant downsides that are worth addressing before merging. Details posted as inline comments; high-level summary below.

Blocking / high-risk

1. cargo install --rev vs tag names. For release triggers the workflow passes github.ref_name (a tag like v1.2.3) into --rev, which cargo documents as a commit SHA selector. This is brittle and may break the release build. Resolve to a SHA via git rev-parse HEAD in the workflow, or pick --tag/--branch/--rev based on input type. (Dockerfile:18, docker.yml:67)

2. arm64 is now compiled under QEMU emulation. The previous workflow built natively on ubuntu-24.04-arm. Rust + QEMU is typically 10–30× slower than native — expect very long arm64 builds and possible timeouts. Suggest restoring the per-arch matrix on native runners and assembling a manifest, plus adding buildx cache. (docker.yml:64)

3. Final image ships the full Rust toolchain + dev headers. Because FROM rust:latest is also the runtime stage, the published image carries build-essential, git, pkg-config, lib*-dev, the toolchain (~1GB+), and the cargo registry/git checkout. A two-stage build (suggested in the inline comment) cleanly fixes this and also addresses the root cause from the PR description by explicitly installing matching runtime lib* packages in the final stage. (Dockerfile:1-21)

Smaller issues

4. ARG TARGETARCH is now unused — can be removed. (Dockerfile:16)
5. No default or guard for STELLAR_CLI_REV — a manual docker build without --build-arg STELLAR_CLI_REV=... produces cargo install --rev "" and a confusing error. (Dockerfile:17)
6. STELLAR_NO_UPDATE_CHECK=1 is a reasonable change but unrelated to the stated PR purpose; worth mentioning in the description or splitting out. (Dockerfile:25)

Nits

• Build context is still context: . but the build no longer reads from it (cargo install pulls from git). Could be set to an empty context to skip the upload, though impact is minor.
• No cache-from/cache-to configured for buildx — every push recompiles everything from scratch.

The core idea (build inside the image so the binary links against the image's libs) is sound, and a two-stage Dockerfile + SHA resolution + restoring native arm64 runners would address all the major concerns while keeping the original motivation intact.
· Branch: docker-cargo

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 84b82db997

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Resolve branch refs before passing them to --rev

For workflow_dispatch runs where ref is a branch name (including the default main), the workflow passes that string through as STELLAR_CLI_REV, but Cargo documents --branch <BRANCH> separately from --rev <SHA> and cargo install --git ... --rev testbranch fails with revspec 'testbranch' not found. This means the manual Docker workflow's default branch build fails in the Dockerfile before pushing; resolve the checked-out ref to a commit SHA for this build arg, or use --branch when the input is a branch.

Useful? React with 👍 / 👎.

[claude]

--rev may break release builds. cargo install --rev is intended for commit SHAs, while the workflow passes github.ref_name for release events — that is the tag name (e.g. v23.1.4). Cargo docs are explicit that --branch, --tag, and --rev are separate selectors with different semantics; relying on --rev to accept a tag name is brittle and may silently break.

Consider resolving the input to a SHA in the workflow before passing it as STELLAR_CLI_REV (e.g. git rev-parse HEAD after checkout, since the workflow already checks out the right ref), or choose the appropriate flag based on whether the input is a tag/branch/SHA.

There is also no default or guard: if someone builds the image locally without --build-arg STELLAR_CLI_REV=..., this becomes cargo install --rev "" stellar-cli, which fails with a confusing error. Adding ARG STELLAR_CLI_REV=main (or a check) would make local builds work and document the intent.

[claude]

ARG TARGETARCH is no longer used (it was only needed to pick the pre-built binary in stellar-${TARGETARCH}/stellar). It can be removed.

[claude]

Cross-arch builds now run under QEMU emulation. The previous workflow built arm64 natively on an ubuntu-24.04-arm runner. With the build matrix removed, the linux/arm64 image is now compiled from source inside QEMU on an amd64 host. Building Rust under QEMU is typically 10–30× slower than native — for a project the size of stellar-cli this can mean very long builds (potentially exceeding the default 6-hour job timeout) and significant CI cost.

Consider keeping the multi-arch matrix and using docker/build-push-action per-arch on native runners, then assembling a manifest with docker buildx imagetools create. Or use buildx with platforms: linux/amd64 on ubuntu-latest and platforms: linux/arm64 on ubuntu-24.04-arm and merge.

Also worth adding cache-from/cache-to (e.g. GHA cache) to avoid re-compiling everything on every push.

[claude]

For workflow_dispatch, inputs.ref can be a branch, tag, or SHA. For release, github.ref_name is the tag (e.g. v1.2.3). Both are forwarded to cargo install --rev in the Dockerfile, which expects a commit SHA (see Dockerfile comment).

Since the workflow already does actions/checkout at the right ref, the simplest fix is to resolve to a SHA here:

- name: Resolve ref to SHA
  id: rev
  run: echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"

# ...
build-args: |
  STELLAR_CLI_REV=${{ steps.rev.outputs.sha }}

This makes the build reproducible and avoids the tag-vs-rev ambiguity.

[claude]

Nit: setting STELLAR_NO_UPDATE_CHECK=1 is a reasonable change for a containerized binary, but it's unrelated to the stated purpose of the PR (build from source). Worth either calling out in the description or splitting into its own commit so the history is clearer.

[Copilot]

Pull request overview

Replaces the Docker image build pipeline that copied a pre-built stellar binary (downloaded from a separate matrix build job) with a single cargo install --git ... --rev "${STELLAR_CLI_REV}" invocation inside the Dockerfile. This ensures the binary links against the libraries actually present in the final image, fixing the runtime libdbus error.

Changes:

• Rewrite Dockerfile to install build toolchain (build-essential, git, pkg-config, *-dev libs) and run cargo install from the public git repo at a specific revision; also set STELLAR_NO_UPDATE_CHECK=1.
• Remove the build matrix job and artifact upload/download steps from .github/workflows/docker.yml; the docker job now passes STELLAR_CLI_REV to docker/build-push-action as a build-arg.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
Dockerfile	Switches from COPY of pre-built binary to in-image cargo install --git --rev; adds dev libs/toolchain and STELLAR_NO_UPDATE_CHECK=1.
.github/workflows/docker.yml	Drops the per-arch build job and binary upload/download; passes STELLAR_CLI_REV build-arg to the multi-platform Docker build.