Pin the NUCLEO Renode download and cache every toolchain fetch

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.

[fdesbiens]

Pin the NUCLEO Renode download and cache every toolchain fetch

Two problems, one of them mine.

1. The NUCLEO Renode download was unpinned and unverified

test-nucleo-renode fetched renode-latest.linux-portable.tar.gz — no version pin, no checksum — while test-polarfire-renode, three jobs above it in the same file, already pinned Renode 1.16.1 and verified its SHA256.

That pin landed in #49, so it was already present when #51 added the NUCLEO job. The new job was modelled on an older copy of the PolarFire step rather than on the current file. The consequence: a regression suite whose emulator could change underneath 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 — it matches.

2. Roughly a gigabyte re-downloaded per run

Artefact	Size	Jobs
xPack RISC-V toolchain	~414 MB	1
Renode portable	~52 MB	2

All three are now restored by actions/cache, keyed on the pinned version so a future bump invalidates the cache rather than silently serving the old one. This completes for the remaining downloads what #53 did for the Arm toolchain.

These two changes are not independent. Caching only makes sense because the artefacts are now pinned — caching an unpinned latest would have frozen CI on whichever build happened to be fetched first, converting a reproducibility gap into an invisible one.

Shape

All four jobs now follow the same structure:

- name: Cache … # actions/cache, key includes the pinned version
- name: Install … # if: cache-hit != 'true'
- name: Put … on PATH # always, so it runs on hit and miss alike

Splitting the PATH export out of the install step is what makes a cache hit usable — folded together, a hit would skip the GITHUB_PATH write and the tool would vanish from the job.

The PolarFire job also gains a version-reporting step, matching the Arm job from #53, so the log records which compiler produced the ELF.

Verification

• Both constructed download URLs resolve (200), with the version substituted exactly as the workflow builds it.
• Renode 1.16.1 SHA256 recomputed from the published tarball: 1a532d4b…9617c, matching what the PolarFire job asserts.
• Workflow YAML parses; all four jobs inspected for the cache / conditional-install / PATH triple.

Cache behaviour itself is only observable on the runner: the first run populates, the second should show hits and skipped installs.