Docker image fails to build contracts when a non-default Rust toolchain is active (`wasm32v1-none` missing)

[leighmcculloch]

What version are you using?

stellar/stellar-cli Docker image, current Dockerfile:

FROM rust:latest
RUN rustup target add wasm32v1-none
...

Reproduced with stellar-cli 26.0.0 image, building a contract that pins Rust 1.95.0 via rust-toolchain.toml.

Real failure: https://github.com/stellar-experimental/contract-verifications/actions/runs/25219981675/job/73949611985

What did you do? (Reproduction steps)

1. Use the stellar/stellar-cli Docker image to build a Soroban contract whose source pins a Rust toolchain different from the image's default (e.g. via rust-toolchain.toml, rustup override, or RUST_TOOLCHAIN).
2. Run a build that targets wasm32v1-none (e.g. stellar contract build, or cargo rustc --target=wasm32v1-none ... inside the container).

The Dockerfile runs rustup target add wasm32v1-none at image build time, which only installs the target for the toolchain that is the default in rust:latest at the moment the image is built. When rustup auto-installs a different toolchain inside the running container, the wasm32v1-none target is not present for it.

What did you expect to see?

The contract builds successfully against whichever Rust toolchain is active in the container, regardless of whether it matches the image's default.

What did you see instead?

error[E0463]: can't find crate for `core`
  |
  = note: the `wasm32v1-none` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32v1-none`
For more information about this error, try `rustc --explain E0463`.
error: could not compile `escape-bytes` (lib) due to 1 previous error
❌ error: exit status exit status: 101
❌ error: build failed inside docker container (exit 1)

Proposed fix

Detect the active Rust toolchain at container runtime and install wasm32v1-none for it before exec'ing the user command, e.g. in entrypoint.sh:

cd /source
rustup target add wasm32v1-none
exec "$@"

Running from /source ensures any rust-toolchain.toml / rust-toolchain in the mounted source is honored. rustup target add is a no-op when the target is already installed for the active toolchain, so this is safe for the default-toolchain case too.

Related

Blocker for, and should be tracked as a subtask of, #2506 (--docker option for reproducible builds, which relies on contracts being able to pin their own toolchain inside the image).