Add build support for all versions on mainnet#22
Conversation
There was a problem hiding this comment.
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.csvandtag_info.txtto capture aggregatedrsver/clivertag counts and derived notes. - Expanded
builds.jsonwith additionalstellar-cliversions 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.
| 1.97.0-nightly,"",1 | ||
| 1.96.0,"",9 |
| 1.75.0,"",45 | ||
| 1.74.1,"",52 | ||
| 1.74.0,"",15 | ||
| "","",11 |
| @@ -0,0 +1,55 @@ | |||
| Tag stats (source: versions.sqlite, 3613 wasm files) | |||
| @@ -3,25 +3,142 @@ | |||
| "$schema": "./builds.schema.json", | |||
| "default_distro": "trixie", | |||
There was a problem hiding this comment.
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
| "rust_versions": [ | ||
| "1.85.0-slim-bookworm@sha256:1829c432be4a592f3021501334d3fcca24f238432b13306a4e62669dec538e52", | ||
| "1.86.0-slim-bookworm@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944", | ||
| "1.87.0-slim-bookworm@sha256:437507c3e719e4f968033b88d851ffa9f5aceeb2dcc2482cc6cb7647811a55eb", | ||
| "1.89.0-slim-trixie@sha256:8cffb8fe4e8a95cf0d6a2060375e5a28aff4c752155aa9f1f9193530769bdf66", |
There was a problem hiding this comment.
💡 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".
| "1.85.0-slim-bookworm@sha256:1829c432be4a592f3021501334d3fcca24f238432b13306a4e62669dec538e52", | ||
| "1.86.0-slim-bookworm@sha256:57d415bbd61ce11e2d5f73de068103c7bd9f3188dc132c97cef4a8f62989e944", | ||
| "1.87.0-slim-bookworm@sha256:437507c3e719e4f968033b88d851ffa9f5aceeb2dcc2482cc6cb7647811a55eb", |
There was a problem hiding this comment.
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 👍 / 👎.
There was a problem hiding this comment.
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
| { | ||
| "ref": "08473ac20016c369067ce0dbca91d9595e72d6d4", | ||
| "rust_versions": [ | ||
| "1.81.0-slim-bookworm@sha256:f9fb6bdb0483de4ade93b262a3f6cf8c2985fca1d34784914bbcabd5a34d3197", |
There was a problem hiding this comment.
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 👍 / 👎.
There was a problem hiding this comment.
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?
|
@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. |
|
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. |
|
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 |
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:
Gives:
While this works successfully: