Workflow Expiry - dated GitHub Actions breakage

There is a category of CI failure that no linter warns you about, because nothing is wrong yet.

On 2026-09-08, this is a completely valid workflow. actionlint passes it. The official GitHub Actions VS Code extension passes it. The schema is correct, the labels exist, the actions resolve.

name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - uses: actions/upload-artifact@v4

Every line in it has a published expiry date.

The two dates in September 2026

2026-09-17 - ubuntu-22.04 and ubuntu-22.04-arm begin deprecation. Full removal is 2027-04-17, and GitHub runs brownout windows before that in which jobs on the image simply fail. Right now the label is valid, so a validity check has nothing to report.

2026-09-23 - Node 20 is removed from the runner. Runners have defaulted to Node 24 since 2026-06-16. Any action whose action.yml declares runs.using: 'node20' stops executing that day, and that includes actions/checkout@v4, actions/setup-node@v4 and v5, and the v4/v5 artifact actions. The ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION escape hatch expires on the same date.

Why a linter cannot tell you this

A linter answers "is this valid?" A calendar answers "is this still valid in three weeks?" Those are different questions and the second one is the one that pages you at 3am.

actionlint does flag an action whose runner is *already* unsupported - node12 and node16 today. It validates runner labels against the list of labels that *currently* exist. Both checks are correct and both are blind to an announced future date, by design. The information you need is not in the file and not in the schema. It is in a changelog post from last year.

What to change

name: ci
on: [push]
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v6
      - uses: actions/upload-artifact@v6

While you are in there, three more things carry dates or teeth:

• ::set-output, ::save-state, ::set-env and ::add-path were removed. They do not error.

They are ignored, so the value downstream is silently empty. Use >> "$GITHUB_OUTPUT".

• uses: some-vendor/action@main pins to a moving branch. Anyone who can force-push that branch

runs code in your pipeline with your secrets. Pin the full 40-character commit SHA.

• ${{ github.event.issue.title }} inside a run: block is shell injection. The title is written

by whoever opened the issue. Pass it through env: and quote "$VAR" in the script.

Checking it

I built a VS Code extension for this, because the check belongs where the file is being edited rather than in a report someone reads quarterly. It carries 29 rules, each one carrying its date and its replacement line, and checking the file you have open is free - all 29 rules, no limit.

There is also a single-page version that runs entirely in the browser: paste a workflow, get the line numbers back. Same rule set, same answers, nothing uploaded.

The thing worth internalising is smaller than the tool: "it passes the linter" and "it will still run next month" are two different claims, and almost nothing in the ecosystem checks the second one.