ci: install Rust in the Linux docker images - #3393
Open
justsmth wants to merge 4 commits into
Open
Conversation
Contributor
|
🔒 Security Review — View Report Please review before merging. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3393 +/- ##
=======================================
Coverage 78.23% 78.23%
=======================================
Files 698 698
Lines 124580 124580
Branches 17285 17287 +2
=======================================
Hits 97471 97471
+ Misses 26184 26183 -1
- Partials 925 926 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
justsmth
marked this pull request as draft
August 4, 2026 17:24
justsmth
force-pushed
the
rust-in-ci-images
branch
from
August 4, 2026 17:48
1c3e756 to
0f33c28
Compare
nhatnghiho
previously approved these changes
Aug 13, 2026
None of the CI images shipped a Rust toolchain, so adding Rust code to AWS-LC would have required image work first. This installs one so the option is there when we want it. Nothing consumes Rust yet. Most images install via rustup into a shared /.rustup and /.cargo using the minimal profile plus clippy and rustfmt, tracking the current stable release. Set RUST_VERSION in a Dockerfile to pin a specific one. Ubuntu 10.04 is pinned to 1.63.0 and installed from the standalone distribution tarball instead. Rust 1.64.0 raised the tier-1 glibc baseline to 2.17 and rustup-init itself requires 2.17, but that image has glibc 2.11. It also cannot reach static.rust-lang.org, so the workflow downloads the tarball on the runner, checksum-verifies it, and passes it in through the existing dependencies build context, the same way its CMake tarball already arrives. The image-build workflows now verify rustc, cargo, and rustfmt alongside the existing Go, CMake, and Perl checks. Also bumps Intel SDE from 9.44.0 to 9.58.0 everywhere it is referenced. Intel removed the 9.44.0 tarball from downloadmirror.intel.com (id 831748 now returns AccessDenied), which was breaking the *_sde image stages and the Windows image build on all branches, including main. 9.58.0 (id 859732) is the last 9.x release; the SDE CPU codes CI uses are unchanged across the bump.
The Intel SDE version, mirror URL, and (new) checksums, plus the Ubuntu 10.04 standalone Rust pin, now live in one file: .github/docker_images/dependencies.env. Previously the SDE pin was hardcoded in 8 files, which made the recent forced bump (Intel deleted the 9.44.0 tarball from its mirror) a shotgun edit and left the copies free to drift. The Dockerfiles now declare the pins as ARGs with no defaults and fail fast with a pointer to dependencies.env when they are not provided. The image-build workflows and the tests/ci build scripts load the env file and pass the values through as --build-arg. dependencies.env is added to the path filters of the consuming workflows so pin bumps trigger image rebuilds. SDE downloads are now also checksum-verified (sha256sum -c on Linux, certutil+findstr on Windows); previously they were not verified at all. Note for reviewers: the Windows image workflow runs the legacy docker builder (DOCKER_BUILDKIT=0), which builds every stage up to the requested target, so the vs2019/vs2022 build steps also execute the SDE-installing vs2017 stage and must receive the build args even though their own stages do not use them. The SDE_MIRROR_URL/SDE_VERSION_TAG env vars in actions-ci.yml were only referenced by a commented-out job and are replaced with a pointer to dependencies.env.
An image-build validation failed with "Unsupported compiler type" for /usr/bin/g++ on an image where the identical check had passed minutes earlier, and the error gave no way to tell what the script actually saw from "g++ --version". Include the captured output (or note that it was empty) in the classification and version-extraction error paths so a recurrence is diagnosable.
justsmth
force-pushed
the
rust-in-ci-images
branch
from
August 14, 2026 16:53
d3a217d to
ba85797
Compare
samuel40791765
approved these changes
Aug 16, 2026
nhatnghiho
approved these changes
Aug 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes:
Installs a Rust toolchain (rustc, cargo, clippy, rustfmt) in all of our Linux CI docker images so that downstream jobs (e.g. aws-lc-rs testing) have Rust available without installing it per-job.
setup-rust.sh, which installs the current stable Rust via rustup with a minimal profile. Used by every image except Ubuntu 10.04.setup-rust-standalone.shfor Ubuntu 10.04, which installs from a pre-downloaded standalone tarball. That image is pinned to Rust 1.63.0 -- the last release that runs on glibc older than 2.17 (1.64 raised the tier-1 baseline, and rustup-init itself requires 2.17). The tarball is downloaded and checksum-verified on the runner, then passed in through the existingdependenciesbuild context, since the image's TLS stack is too old to reach static.rust-lang.org (same reason its CMake tarball is sourced that way).verify-rust-version.shand wires it into every image-build workflow's container validation step. Most images just verify the tools are present and working; Ubuntu 10.04 additionally pins rustc/cargo to 1.63.Call-outs:
CARGO_HOME/RUSTUP_HOMEare made world-writable so non-root CI jobs (seecodebuild/common/run_nonroot_target.yml) can write cargo's registry caches. The official rust docker image does the same.setup-rust.shomits the--tlsv1.2flag from the canonical rustup install line because CentOS 7's curl (7.29) predates it, and falls back to wget on Ubuntu 16.04, which has no curl.RUST_VERSIONcan be set to pin if that ever becomes a problem.ccsymlink is created (pointing at gcc-4.1) because rustc invokesccas its linker driver and that image only installs versioned compilers.Testing:
Each image-build workflow now runs
verify-rust-version.shfor rustc, cargo, and rustfmt inside the built container. These workflows trigger on this PR since it touches.github/docker_images/scripts/**.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.