Skip to content

Swatinem/rust-cache is pinned to an unreleased master commit while the comment claims # v2 #102

Description

@plusky

Summary

Every action in this repo is SHA-pinned with a # vX comment naming the
release the SHA belongs to. For Swatinem/rust-cache that comment is
misleading: the pinned SHA is not a release, it is whatever commit was at the
tip of the action's default branch when Dependabot last looked.

Established while reviewing #100:

pin commit vs the v2 tag
before #100 (a45951ff) merge of an upstream Dependabot PR, 2026-08-10 2 commits ahead
after #100 (258712b0) fix: stop cleanup timestamp pruning after the first entry (#377), 2026-08-12 3 commits ahead

Neither SHA has any tag pointing at it. The v2 tag resolves to 49a0bdc7,
and the latest release is v2.9.2. Both pins are post-release commits off
master.

Contrast #99, landing at the same time, which moved github/codeql-action
from 5595ccaf to ff2f1c62 — and that SHA really is tagged, v4.37.7
(and v4). So two bumps that look identical in the diff have materially
different provenance, and nothing in the file says which is which.

Why it matters

The comment is the only signal a reader gets about what a 40-hex string is,
and here it asserts a release that the SHA is not. Someone auditing the
workflow, or deciding whether a bump is safe to wave through, reasonably
reads # v2 as "this is v2" and stops. The actual position — running
unreleased code from a third-party action's default branch, on a runner that
touches ~/.cargo and target/ — is a deliberate-looking choice nobody
appears to have made deliberately.

This is not a regression from #100: the previous pin had the same property,
so the posture predates it. That is precisely why it is worth writing down —
it is invisible, and every future bump preserves it silently.

Not a licence problem

Unrelated to the LGPL-3.0 exemption in .github/workflows/dependency-review.yml.
Worth noting that #100 was the first bump to actually exercise that exemption
(the check only inspects changed dependencies, so it had been dormant since
it was added in #82) and it passed.

Options

  1. Accept and document — change the comment to something honest, e.g.
    # master @ 2026-08-12, post-v2.9.2 or just # unreleased, tracks default branch, so the file stops claiming a release.
  2. Pin to releases — move to the v2.9.2 tag's commit and configure
    Dependabot so rust-cache follows releases rather than the branch.
  3. Drop the action — it is only a cache; ci.yml uses it in 5 places and
    release.yml deliberately does not (see the reasoning in
    dependency-review.yml). Removing it costs build time and nothing else.

Option 2 matches what every other pin in the repo already implies. Option 1
is the cheap honest fix if branch-tracking is actually wanted.

Found while reviewing #100.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions