ci(release): wait for the installer fixture server to actually serve - #9
Merged
Merged
Conversation
Both installer rehearsals start `http.server` in the background and then `sleep 1` before pointing the installer at it. The Windows rehearsal failed twice in a row on v0.1.13 with Invoke-WebRequest: No connection could be made because the target machine actively refused it. and nothing else: the server's own output went to a hidden window, so a server that never came up looked exactly like a broken installer. Wait for the port to accept instead of guessing, and fail with the server's output when it never does. Both rehearsals get it; the POSIX one has the same race and has simply been luckier. On Windows, also refuse the Microsoft Store alias stub. It is named `python`, it is on PATH, and it starts — so `Start-Process` succeeds and `$server.HasExited` stays false — while serving nothing, which matches the failure exactly. Resolving `python`/`python3` past `WindowsApps` and capturing stderr turns that into a named error rather than a refused connection six seconds later. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Why
The v0.1.13 release run failed on
package (x86_64-pc-windows-msvc), and failed again identically on re-run — so not a flake:Both installer rehearsals background a
http.serverand thensleep 1before pointing the installer at it. Two problems:-WindowStyle Hidden, no redirect), POSIX sends it to/dev/null. A server that never came up is indistinguishable from a broken installer — which is exactly how this presented.Change
Wait for the port to accept, with a 30s budget, and fail with the server's captured output when it never does. Applied to both rehearsals; the POSIX one carries the same race and has simply been luckier.
On Windows, also refuse the Microsoft Store alias stub. It is named
python, it sits on PATH, and it starts — soStart-Processsucceeds and$server.HasExitedstays false — while serving nothing. That matches the observed failure precisely. Resolvingpython/python3pastWindowsAppsand capturing stderr turns it into a named error instead of a refused connection six seconds later.Note on v0.1.13
The tag is already pushed and its release never published. Once this is on
main, the release is re-run viaworkflow_dispatchwithtag: v0.1.13— that path takes the workflow definition from the default branch while still checking out the tag (RELEASE_REF), so the fix applies without moving or re-cutting the tag.actionlintclean.🤖 Generated with Claude Code