ci(LINCHPIN-5650): Stop cancelling Pages deploys and silence the preview 404 - #11
Merged
Merged
Conversation
…w a favicon Two faults on the published Storybook, neither of which breaks a story - all 24 render on the live site - and both of which show up as errors. Merging four PRs in five minutes left two Pages deployments in error and a third hung: 6572461154 and 6572501867 both failed, and 6572553280 sat in_progress for minutes on a build that had finished in 38 seconds. The cause is cancel-in-progress on a deploy. A run cancelled after it has opened a Pages deployment abandons it, and the next run then contends with the wreckage. That setting is right for a build and wrong for a deploy, which is why GitHub's own Pages workflow ships it as false with a comment saying so. Nothing is wasted by the change: runs queued behind an in-flight deployment still collapse to the latest, so intermediate commits are skipped rather than deployed one after another. Only the cancellation goes away. Separately, every story on the deployed site logged a 404. The manager carries an icon link and iframe.html does not, so the browser falls back to asking the origin root for favicon.ico - and on a project Pages site that root belongs to the organisation, not to us, so it answers 404 forever. preview-head.html puts the same relative link in the preview head. Verified by building and serving the output: the fixed build logs zero console errors and zero warnings on a story page, against one error on every story of the deployed one, and all 24 stories still render with the icon link present.
The deploy job had none, so it inherited the six hour default while the build beside it was capped at fifteen minutes. Deployment 6572553280 is sitting in_progress well past the 38 seconds its build took, and nothing would have stopped it holding the lane until tomorrow. This matters more now the concurrency group no longer cancels. Under the old setting a stuck deploy was at least shoved aside by the next push; under the new one later runs queue behind it, so a hang has to fail on its own or nothing deploys at all. Ten minutes is generous for a job whose work is uploading an artifact GitHub has already built.
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.
Two faults on the published Storybook. Neither breaks a story — all 24 render on the live site with no error overlay, which I verified before changing anything — but both surface as errors.
ClickUp: LINCHPIN-5650 — a subtask of LINCHPIN-5639.
1. Cancelled runs abandon Pages deployments
Merging #7, #8, #9 and the 0.2.1 release PR inside five minutes produced three cancelled runs and this:
The build was never the problem — it finished in 38 seconds. The
Deployjob is what hangs, becausecancel-in-progress: truekills a run after it has opened a Pages deployment. The deployment is abandoned, ends inerror, and the next run contends with it.That setting is right for a build and wrong for a deploy, which is why GitHub's own Pages workflow ships it as
falsewith a comment saying exactly this:Nothing is wasted by the change. Runs queued behind an in-flight deployment still collapse to the latest, so intermediate commits are skipped rather than deployed one after another. Only the cancellation goes away.
2. Every story logged a 404
The manager carries
<link rel="icon" type="image/svg+xml" href="./favicon.svg" />and/ui/favicon.svgserves 200.iframe.html— where every story actually renders — carried no icon link, so the browser fell back to the origin root:On a project Pages site that root belongs to the org, not to us, so it answers 404 forever.
.storybook/preview-head.htmlputs the same relative link in the preview head.3. The deploy job had no timeout
It inherited the six-hour default while the build beside it was capped at fifteen minutes. This matters more after change 1: under the old setting a stuck deploy was at least shoved aside by the next push; under the new one later runs queue behind it, so a hang has to fail on its own or nothing deploys. Ten minutes is generous for uploading an artifact that is already built.
Verification
Built the site and served it locally:
iframe.htmlicon linkThe 24/24 figure on the deployed column is from sweeping the live site before making any change — worth stating, because it means the story fixes from earlier today did deploy correctly and this PR is not repairing those.
Before this can take effect
Deployment 6572553280 is still hung. With
cancel-in-progress: falsea stuck deployment blocks the queue rather than being replaced, so that run needs cancelling before a new deploy can land. The timeout in change 3 prevents a recurrence but cannot retrospectively free this one.