ci(docs): pin the Pages actions back to the pair that works - #23
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
deploy-pages@v5aborts this repo's deploy with "Timeout reached" after ~1 minute of pollingupdating_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
a217c63ff347b2CI 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, andaction-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.