Skip to content

ci(docs): pin the Pages actions back to the pair that works - #23

Merged
piotrlaczkowski merged 2 commits into
mainfrom
fix/pages-deploy-regression
Aug 27, 2026
Merged

ci(docs): pin the Pages actions back to the pair that works#23
piotrlaczkowski merged 2 commits into
mainfrom
fix/pages-deploy-regression

Conversation

@piotrlaczkowski

Copy link
Copy Markdown
Contributor

deploy-pages@v5 aborts this repo's deploy with "Timeout reached" after ~1 minute of polling updating_pages — twice in a row, including a clean re-run.

The artifact uploads fine and Build MkDocs passes; only the deploy step fails, so the published site is stuck on the previous commit's build.

Why the pair is the variable

Commit Actions Docs result
a217c63 upload-pages-artifact@v3 + deploy-pages@v4 ✅ success
ff347b2 upload-pages-artifact@v5 + deploy-pages@v5 ❌ failure (×2)

CI and Vulnerability scan were green on ff347b2, so this is isolated to the Pages deploy.

Scope

Only these two are reverted. The rest of the Actions sweep from #22 stays and is green: checkout@v7, setup-go@v7, setup-node@v7, setup-python@v7, and action-gh-release@v3.

That last one matters because it's the step that publishes releases — I checked its notes and v3.0.0 is only a Node 20→24 runtime move, no input or behaviour changes, and GitHub-hosted runners already support Node 24.

Reopen the bump when v5 has a fix.

deploy-pages@v5 aborts this repo's deploy with "Timeout reached" after about a
minute of polling — twice in a row, including a clean re-run. The artifact
uploads fine and Build MkDocs passes; only the deploy step fails, and the
published site is therefore stuck on the previous commit's build.

The same workflow on upload-pages-artifact@v3 + deploy-pages@v4 succeeded on
a217c63, the commit immediately before the bump, and CI and the vulnerability
scan were green on the bumped commit too. The action pair is the variable.

Only these two are reverted. The rest of the Actions sweep stays: checkout 7,
setup-go 7, setup-node 7, setup-python 7 and action-gh-release 3 are all in use
and green — the last is only a Node 20→24 runtime move with no input changes,
which matters because it is the step that publishes releases.
StartInputPump launches its read loop immediately; SetHotkeys installs the
filter afterwards. With the input already buffered in a strings.Reader, the
pump can read and classify 'y' before the filter lands, and the test then sees
a plain rune event where it asserted a hotkey:

    --- FAIL: TestInputPumpHotkeyFilter
        keys_test.go:177: got {Kind:1 Line: Key:y}

The race is in the test's setup, not in the pump — the filter is mutex-guarded
either way. A pipe written only after SetHotkeys returns makes the ordering the
test means to assert the one it actually gets. Passes 40 consecutive -race runs.

Surfaced on a loaded CI runner while merging the dependency backlog; unrelated
to those bumps, and it would have kept flaking the release gate.
@piotrlaczkowski
piotrlaczkowski merged commit bf04b6d into main Aug 27, 2026
7 checks passed
@piotrlaczkowski
piotrlaczkowski deleted the fix/pages-deploy-regression branch August 27, 2026 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant