Summary
Our CI/CD workflows pin GitHub Actions to the moving @master branch instead of a stable major-version tag like @v4. This means every workflow run silently picks up whatever HEAD of actions/checkout, actions/setup-node, and actions/cache happens to be — there is no diff in this repo when those upstream branches change, so a green PR yesterday can fail today for reasons we cannot see.
Affected workflows
All inherited from before the test-harness conversion (PR #524). Not introduced by recent work — long-standing drift.
.github/workflows/ci_dev.yaml — 6 occurrences.github/workflows/ci_prod.yaml — 9 occurrences.github/workflows/cd_dev.yaml — 4 occurrences.github/workflows/cd_prod.yaml — 4 occurrences.github/workflows/test_pushes.yaml — 3 occurrences
Total: ~27 @master references across 5 workflows.
The new .github/workflows/sync_tpen_shared_openapi.yaml already pins actions/checkout@v4 correctly, so the inconsistency exists internally too.
Why this matters
- Reproducibility — same YAML produces different behavior over time.
- Supply-chain surface — a malicious or accidental commit to
actions/checkout's master branch propagates to every run immediately.
- Breaking changes — when
actions/checkout@v5 ships, @master consumers get the breakage at the next run with no warning.
- GitHub's own guidance explicitly recommends pinning to a major version tag or a SHA. Major-version tags (
@v4) still receive patch/security updates automatically.
Cross-repo alignment
- RERUM v1 (
CenterForDigitalHumanities/rerum_server_nodejs) already uses @v4 across all CI/CD workflows.
- TinyPEN (
CenterForDigitalHumanities/TinyPen) has the same @master drift — tracked separately in a TinyPen issue.
Proposed fix
Normalize all five workflows to:
actions/checkout@v4actions/setup-node@v4actions/cache@v4
Single-PR sweep, no behavior changes expected (all three actions' @v4 tag is the latest stable major and what RERUM v1 already runs on).
Acceptance criteria
Out of scope
- Pinning to commit SHAs — first-party
actions/* major-version tags are sufficient.
- Migrating to a different Node setup action.
- TinyPEN cleanup — separate issue.
Summary
Our CI/CD workflows pin GitHub Actions to the moving
@masterbranch instead of a stable major-version tag like@v4. This means every workflow run silently picks up whatever HEAD ofactions/checkout,actions/setup-node, andactions/cachehappens to be — there is no diff in this repo when those upstream branches change, so a green PR yesterday can fail today for reasons we cannot see.Affected workflows
All inherited from before the test-harness conversion (PR #524). Not introduced by recent work — long-standing drift.
.github/workflows/ci_dev.yaml— 6 occurrences.github/workflows/ci_prod.yaml— 9 occurrences.github/workflows/cd_dev.yaml— 4 occurrences.github/workflows/cd_prod.yaml— 4 occurrences.github/workflows/test_pushes.yaml— 3 occurrencesTotal: ~27
@masterreferences across 5 workflows.The new
.github/workflows/sync_tpen_shared_openapi.yamlalready pinsactions/checkout@v4correctly, so the inconsistency exists internally too.Why this matters
actions/checkout's master branch propagates to every run immediately.actions/checkout@v5ships,@masterconsumers get the breakage at the next run with no warning.@v4) still receive patch/security updates automatically.Cross-repo alignment
CenterForDigitalHumanities/rerum_server_nodejs) already uses@v4across all CI/CD workflows.CenterForDigitalHumanities/TinyPen) has the same@masterdrift — tracked separately in a TinyPen issue.Proposed fix
Normalize all five workflows to:
actions/checkout@v4actions/setup-node@v4actions/cache@v4Single-PR sweep, no behavior changes expected (all three actions'
@v4tag is the latest stable major and what RERUM v1 already runs on).Acceptance criteria
@masterreferences remain in.github/workflows/.actions/checkout,actions/setup-node,actions/cachereferences pin a major version tag (@v4).Out of scope
actions/*major-version tags are sufficient.