Add build support for all versions on mainnet

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract

[ethanfrey]

I ran an analysis on all wasm hashes on Soroban mainnet, and extracted the cliver and rsver from their data (see tags.csv and tag_info.txt). Many are from pre-v23.2.0 versions and don't have clear cliver marking.

Of the newer ones, I was able to find all (cliver, rsver) pairs and updated builds.json so it can produce build images needed to verify existing contracts on mainnet (part of the RFP for contract verification).

This exposed one issue in the underlying design. People are compiling contracts with rustc versions that are too old to compile the stellar-cli command itself. This actually suggests downloading release builds from github rather than building it in the docker file.

Examples:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.86.0-slim-bookworm --rust-image-digest sha256:57d
415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944

Gives:

building stellar-cli:23.2.1-rust1.86.0-slim-bookworm
stellar-cli 23.2.1 (496ac35be7a7d8d923fcde9bbbc650ee593d1f6f)
rust 1.86.0-slim-bookworm (sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944)
base rust:1.86.0-slim-bookworm
platform <host native>
[+] Building 4.1s (9/14) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.83kB 0.0s
=> resolve image config for docker-image://docker.io/docker/dockerfile:1.10 0.6s
=> CACHED docker-image://docker.io/docker/dockerfile:1.10@sha256:865e5dd094beca432e8c0a1d5e1c465db5f998dca4e439981029b3b81fb39ed5 0.0s
=> [internal] load metadata for docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 120B 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/rust@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944 0.0s
=> CACHED [builder 2/4] RUN apt-get update && apt-get install -y --no-install-recommends build-essential ca-certificates git 0.0s
=> CANCELED [stage-1 2/6] RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libdbus-1-3 libssl3 3.3s
=> ERROR [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcd 3.3s
------ > [builder 3/4] RUN cargo install --locked --root /out --git https://github.com/stellar/stellar-cli.git --rev "496ac35be7a7d8d923fcde9bbbc650ee593d1f6f" stellar-cli: 0.147 Updating git repository `https://github.com/stellar/stellar-cli.git` 3.288 error: cannot install package `stellar-cli 23.2.1`, it requires rustc 1.89.0 or newer, while the currently active rustc version is 1.86.0 ------ 

While this works successfully:

./scripts/build_image.py --stellar-cli-version 23.2.1 --rust-version 1.91.1-slim-trixie --rust-image-digest sha256:f75071363e7f4771769d4cf81b1b7b290e607f4d4459e8731f6abdcee9982dc8
docker run --rm stellar-cli:23.2.1-rust1.91.1-slim-trixie contract build --help

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds version/tag statistics and expands the build matrix for stellar-cli to cover more historical releases and Rust toolchains.

Changes:

• Added tags.csv and tag_info.txt to capture aggregated rsver/cliver tag counts and derived notes.
• Expanded builds.json with additional stellar-cli versions and a broader set of pinned Rust image variants per version.

Reviewed changes

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

File	Description
tags.csv	Introduces aggregated counts by rsver and cliver for downstream analysis and build targeting.
tag_info.txt	Adds a human-readable summary of tag stats and a candidate list of stellar-cli versions needing images.
builds.json	Expands the supported stellar-cli versions and pins more Rust image digests for reproducible builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ethanfrey]

The older rust versions only have a bookworm variant and not a trixie variant.

Also, the defualt_distro should be trixie-slim I believe according to this comment

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:cb4d64f45c

ℹ️ 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]

Avoid declaring Rust bases older than the CLI MSRV

When publishing v23.2.1, publish.yml resolves every pin in this list and the Dockerfile uses that same rust@... base to run cargo install --locked for the CLI. stellar-cli 23.2.1 requires rustc 1.89.0 or newer, so these 1.85/1.86/1.87 rows fail during the release matrix instead of producing verification images; please don't add sub-MSRV runtime pins until the image can install a prebuilt CLI or otherwise decouple the CLI build toolchain from the contract Rust toolchain.

Useful? React with 👍 / 👎.

[ethanfrey]

You are right to flag this issue, but we actually need to add these rustc versions as they are using in production contracts.

I think the proper solution is to use a different rustc to builds stellar-cli than the one used to compile the contracts. See #23

[chatgpt-codex-connector]

Do not add Rust 1.81 without handling wasm32v1-none

This row is selected by resolve_matrix.py for a v23.3.0 publish, but the Dockerfile always runs rustup target add wasm32v1-none in the runtime stage. That target is only available on Rust 1.84.0 and newer, so the 1.81.0 image build will fail before it can be published; either exclude this pin or change the image logic for pre-1.84 contract toolchains.

Useful? React with 👍 / 👎.

[ethanfrey]

Very interesting point here. How did people compile contracts pre-1.84.0?

I think this docker build problem is actually much more complicated than believed when it actually aims to support verifying existing deployed contracts. Maybe there are a few different build paths and different docker files for the different historical artifacts. What target did v23.3.0 use to compile?

[fnando]

@ethanfrey because anything already uploaded to the chain will lack the metadata required by SEP-58, I don't think we should be adding all older rust+cli combinations to the matrix. Instead, we should focus on the newest releases, at least for now.

We have an exception which is 25.1.0, because we're working with a partner (who actually triggered this work) that already audited their contracts with this given CLI+rust version, so we're kinda beta-testing them.

cc @leighmcculloch

[leighmcculloch]

I think there's a compromise in here. I think folks who want to have their contract verified can open an issue requesting that specific configurations get added. I don't think we need to proactively build a large number of images, many of them will not get used.

[ethanfrey]

Okay, I was confused. I understood this repo as trying to build clear cli-rust docker pairs to retroactively validate existing contracts. Moving forward they would all use existing docker images to build and thus be easy to verify

I’ve been researching a lot the back verification for the RFP and I guess ended up a bit single minded focus.

If that is not the purpose of this repo, I will just do it on a fork and build my images so I can start testing existing projects. And only PR specific cases here once I have a successful run verifying a contract