Three pin inconsistencies, found by diffing this repo's CI against rpt and qwt. None is breaking today; all three are the kind of drift that goes unnoticed because nothing fails.
1. actions/checkout@v4 — three majors behind the sibling templates
.github/workflows/check-spelling.yaml:22 and lint-project.yaml use actions/checkout@v4, while rpt and qwt both use @v7 everywhere.
This is the one with a real deadline attached: @v4 runs on the Node 20 runtime, which GitHub is winding down in favour of Node 24. Actions on a retired runtime start emitting deprecation warnings and eventually stop running. Bumping to @v7 matches the siblings and gets ahead of it.
2. r-spellcheck-action@v3.0.2 vs v3.0.3
.github/workflows/check-spelling.yaml:25 pins insightsengineering/r-spellcheck-action@v3.0.2. Both rpt and qwt are on v3.0.3.
Minor, but the three templates should not silently spellcheck to different rules — a book generated from qbt would behave differently from one generated from qwt for no stated reason.
3. summary.yml@v2 should be @v1
.github/workflows/summary.yml:17 calls:
uses: d-morrison/gha/.github/workflows/summary.yml@v2
The documented pin for this capability is @v1. From gha's README (the Versioning section):
summary.yml, bump-submodule.yml, and sync-shared-fragments.yml were audited in the same pass and found unchanged since the freeze, so @v1 remains current for them.
gha's own examples/summary.yml and website/reference/summary.qmd both show @v1, and rpt uses @v1. @v2 resolves (the major tag is repo-wide) and currently runs identical content, so nothing is broken right now — but it means this repo would silently pick up any future change to summary.yml that @v1 consumers deliberately would not.
To be clear about the direction: rpt is correct here and this repo is the outlier. Worth stating because the reflex on seeing a @v1 next to a @v2 is to assume the @v1 is stale.
Also worth noting
qbt has no .github/dependabot.yml, while rpt and qwt both do (github-actions + gitsubmodule, weekly). That absence is why these pins drifted in the first place — the siblings get bump PRs automatically and this repo does not. Adding the same config would prevent a recurrence, and is probably the more valuable half of this issue.
Three pin inconsistencies, found by diffing this repo's CI against
rptandqwt. None is breaking today; all three are the kind of drift that goes unnoticed because nothing fails.1.
actions/checkout@v4— three majors behind the sibling templates.github/workflows/check-spelling.yaml:22andlint-project.yamluseactions/checkout@v4, whilerptandqwtboth use@v7everywhere.This is the one with a real deadline attached:
@v4runs on the Node 20 runtime, which GitHub is winding down in favour of Node 24. Actions on a retired runtime start emitting deprecation warnings and eventually stop running. Bumping to@v7matches the siblings and gets ahead of it.2.
r-spellcheck-action@v3.0.2vsv3.0.3.github/workflows/check-spelling.yaml:25pinsinsightsengineering/r-spellcheck-action@v3.0.2. Bothrptandqwtare onv3.0.3.Minor, but the three templates should not silently spellcheck to different rules — a book generated from
qbtwould behave differently from one generated fromqwtfor no stated reason.3.
summary.yml@v2should be@v1.github/workflows/summary.yml:17calls:The documented pin for this capability is
@v1. Fromgha's README (the Versioning section):gha's ownexamples/summary.ymlandwebsite/reference/summary.qmdboth show@v1, andrptuses@v1.@v2resolves (the major tag is repo-wide) and currently runs identical content, so nothing is broken right now — but it means this repo would silently pick up any future change tosummary.ymlthat@v1consumers deliberately would not.To be clear about the direction:
rptis correct here and this repo is the outlier. Worth stating because the reflex on seeing a@v1next to a@v2is to assume the@v1is stale.Also worth noting
qbthas no.github/dependabot.yml, whilerptandqwtboth do (github-actions+gitsubmodule, weekly). That absence is why these pins drifted in the first place — the siblings get bump PRs automatically and this repo does not. Adding the same config would prevent a recurrence, and is probably the more valuable half of this issue.