Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern - #53
Merged
Merged
Conversation
… pattern
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release
at the time. eclipse-threadx/threadx already pins 14.3.rel1 in
ci_cortex_m.yml for the Cortex-M ports, so samplex was lagging the flagship
repository rather than choosing between two versions. Both satisfy the
AGENTS.md GCC 14 requirement; matching threadx means a toolchain bump is one
reviewable line in each repository instead of a per-repository decision.
The install steps now mirror ci_cortex_m.yml rather than paraphrasing it,
which fixes three weaknesses in the version this replaces:
- The archive was fetched with no integrity check at all. It is now
verified with sha256sum against the published .sha256asc.
- Roughly 150 MB was downloaded on every run. actions/cache, keyed on the
pinned version, now avoids that.
- wget -q hid transfer detail. curl -fsSL fails the step on an HTTP error,
and a new step reports the resulting compiler version so the log records
what actually built the ELF.
Version and target move into job env vars (GCC_VERSION, GCC_TARGET) using the
same names threadx uses, so the two files stay diffable and a future bump is
a one-line change.
Re-measured the NUCLEO validation record under the newly pinned compiler:
22064 B ROM, down 4 bytes from 14.2.1; RAM unchanged at 6000 B. The figures
and the pin move together deliberately, since letting them drift is what left
a stale 15.2.1 measurement in this file before.
Verified under Arm GNU Toolchain 14.3.Rel1: clean build with -Wall -Wshadow
-Wdouble-promotion -Werror, no new diagnostics from the point release, and
the headless Renode suite still passes with all seven startup self-tests.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 31, 2026
fdesbiens
added a commit
that referenced
this pull request
Aug 31, 2026
Two problems in the pipeline, one of them mine. The NUCLEO Renode job fetched renode-latest.linux-portable.tar.gz with no version pin and no checksum, while the PolarFire job three jobs above it already pinned Renode 1.16.1 and verified its SHA256. That pin landed in #49, so it was present in this file when #51 added the NUCLEO job; the new job was modelled on an older copy of the PolarFire step rather than the current one. The result was a suite whose emulator could change under it on any Renode release, with nothing verifying what was downloaded. The NUCLEO job now uses the same pinned, checksum-verified step as PolarFire. The checksum was recomputed from the published artefact rather than copied on trust. Separately, every run re-downloaded roughly a gigabyte: the xPack RISC-V toolchain at ~414 MB and Renode at ~52 MB in each of two jobs. All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache instead of silently serving the old one. This completes what #53 started for the Arm toolchain. Caching only makes sense because these are now pinned. Caching an unpinned "latest" artefact would have frozen CI on whichever build happened to be fetched first, turning a reproducibility gap into an invisible one. All four jobs now follow the same shape: cache, install only on a cache miss, then put the tool on PATH as a separate step so it runs on hit and miss alike. The PolarFire job also gains a version-reporting step, matching the Arm job, so the log records which compiler produced the ELF. Verified both constructed download URLs resolve, and that the Renode 1.16.1 checksum matches the published artefact. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Pin the Arm toolchain to 14.3.Rel1 and adopt the ThreadX install pattern
Why
The ARM job pinned 14.2.Rel1, chosen only because it was the newest release I was aware of when #50 added the pin.
eclipse-threadx/threadxalready pins 14.3.rel1 inci_cortex_m.ymlfor the Cortex-M ports — so samplex was lagging the flagship repository rather than choosing between two versions.Both satisfy the AGENTS.md GCC 14 requirement. Matching
threadxmeans a toolchain bump becomes one reviewable line in each repository instead of a per-repository decision.What changed
The install steps now mirror
ci_cortex_m.ymlrather than paraphrasing it, which fixes three weaknesses in the version this replaces:sha256sum -cagainst the published.sha256ascactions/cachekeyed on the pinned versionwget -q, no version recordedcurl -fsSL(fails the step on HTTP errors) plus a step reporting the compiler version into the logVersion and target move into job
envvars (GCC_VERSION,GCC_TARGET) using the same namesthreadxuses, so the two files stay diffable.Validation record re-measured
The figures and the pin move together deliberately — letting them drift is what left a stale 15.2.1 measurement in this README before.
Verification
Locally under Arm GNU Toolchain 14.3.Rel1 (GCC 14.3.1 20250623):
-Wall -Wshadow -Wdouble-promotion -Werror— the point release introduces no new diagnostics..sha256ascreturn 200 from the pinned URL.Not in scope
PolarFire's RISC-V toolchain stays on xPack 14.2.0 — a different vendor on a different release cadence, and AGENTS.md's GCC 14 requirement is satisfied. The xPack and Renode downloads in the other jobs could take the same caching and checksum treatment; worth a follow-up, but kept out of this change so the diff stays reviewable.