Summary
Our CD workflows pin GitHub Actions to the moving @master branch instead of a stable major-version tag like @v4. 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
.github/workflows/cd_dev.yaml — 5 occurrences (3× actions/checkout@master, 1× actions/setup-node@master, 1× actions/cache@master)
.github/workflows/cd_prod.yaml — 2 occurrences of actions/checkout@master
Our newer workflows (tests.yaml, shared_openapi_sync.yaml) already pin actions/checkout@v4 and actions/setup-node@v4, so the inconsistency is internal to this repo 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
Proposed fix
Normalize the two CD workflows to:
actions/checkout@v4
actions/setup-node@v4
actions/cache@v4
Small, contained sweep; no behavior changes expected (these are the same versions the existing tests.yaml and shared_openapi_sync.yaml already run on).
Acceptance criteria
Out of scope
- Pinning to commit SHAs — first-party
actions/* major-version tags are sufficient.
- TPEN-services and TinyPEN cleanups — separate issues.
Summary
Our CD workflows pin GitHub Actions to the moving
@masterbranch instead of a stable major-version tag like@v4. 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
.github/workflows/cd_dev.yaml— 5 occurrences (3×actions/checkout@master, 1×actions/setup-node@master, 1×actions/cache@master).github/workflows/cd_prod.yaml— 2 occurrences ofactions/checkout@masterOur newer workflows (
tests.yaml,shared_openapi_sync.yaml) already pinactions/checkout@v4andactions/setup-node@v4, so the inconsistency is internal to this repo 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.Proposed fix
Normalize the two CD workflows to:
actions/checkout@v4actions/setup-node@v4actions/cache@v4Small, contained sweep; no behavior changes expected (these are the same versions the existing
tests.yamlandshared_openapi_sync.yamlalready run on).Acceptance criteria
@masterreferences remain in.github/workflows/.actions/checkout,actions/setup-node,actions/cachereferences in CD workflows pin to@v4.Out of scope
actions/*major-version tags are sufficient.