[ci] Properly parse Rust nightly versions - #705
Conversation
c3d75b8 to
12f3193
Compare
withjannisNLnetLabs
left a comment
withjannisNLnetLabs
left a comment
There was a problem hiding this comment.
Some nit/questions, but I think the main thing is the rust version specified in toolchain.
| - name: Restore from cache | ||
| id: cache-restore | ||
| uses: actions/cache/restore@v6 |
There was a problem hiding this comment.
I just noticed that in the clippy version you don't restore from cache under certain conditions (workflow/schedule), but in this version there is no condition. I assume that is missing here? Because this way you would have a clean cache, without artifacts from older versions.
There was a problem hiding this comment.
The unconditional restore here was intentional. When building a new cache from scratch for Clippy, we don't want to use the old cache, because it was tied to a particular Rust nightly version. Under the schedule/workflow_dispatch events, we want to use the latest Rust nightly version, not the one from the cache, so that it doesn't get stale. In that situation, we could choose to restore the cache but still use the latest Rust nightly version; but then the cache would almost certainly be wasted. For this job, we don't need to explicitly update the Rust compiler version, and it probably changes very rarely, so restoring the cache is probably helpful.
12f3193 to
8c48fd0
Compare
It's simpler, almost certainly faster, and poses less of a security risk.
8c48fd0 to
ee4097d
Compare
2 participants
The job currently set
nightly-x86_64-unknown-linux-gnuwhere it should have beennightly-2026-07-24. The former version specification changes meaning every day (night?).