Raise deploy-pages' own timeout, not just the job's - #41
Merged
Conversation
PR #40 raised the deploy job to 30 minutes and the very next deploy still failed at 10m10s. The cap that fired was the action's, not the job's: deploy-pages takes a `timeout` input, defaults it to 600000 ms, and polls until then. Two independent ten-minute limits, so raising one moved the failure by ten seconds. The consequence is worse than a red run. On timeout the action cancels the deployment, and the deployment is keyed by commit SHA -- so re-running that workflow creates a deployment for the same SHA, is handed the cancelled state, and fails in ten seconds with "Deployment cancelled." Observed exactly that. A merged docs change then cannot be published at all without a new commit, which is why this one exists. Set to 20 minutes, deliberately under the job's 30, so the action times out and reports instead of being killed mid-flight. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mbakalarski
added a commit
that referenced
this pull request
Aug 6, 2026
The timeout raised in #41 never applied. The action accepts a larger value, warns, and clamps it back: Warning: timeout value is greater than the allowed maximum - timeout set to the maximum of 600000 milliseconds. So a Pages deploy can never wait longer than ten minutes, and no setting in this repository changes that. The input is dropped again; what is worth keeping is the comment saying why raising it is not an option, since the obvious fix looks available and is not. Co-authored-by: Claude Opus 5 <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
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.
#40 raised the deploy job to 30 minutes. The very next deploy still failed, at
10m10s — so the limit that fired was never the job's.
actions/deploy-pageshas its owntimeoutinput, default600000ms, andpolls the Pages backend until then:
Two independent ten-minute limits. Raising one moved the failure by ten seconds.
Why this needed a new commit rather than a re-run
On timeout the action does not just give up — it cancels the deployment, and
the deployment is keyed by commit SHA. Re-running the workflow creates a
deployment for that same SHA, is handed the cancelled state, and fails at once:
Ten seconds, versus ten minutes the first time. So a merged docs change becomes
unpublishable until some new commit lands.
install.mdfrom #39 is in exactlythat state on
mainright now, and merging this releases it.The value
20 minutes, deliberately under the job's 30, so the action times out and reports
rather than being killed mid-flight. The underlying slowness is GitHub's — every
poll returned
deployment_queued— andnetclab.github.iomeasured 8m04s and9m12s for the same shape of deploy the same day, close enough to ten minutes that
this was going to fire sooner or later.
netclab.github.io/.github/workflows/pages.ymlneeds the same input and doesnot have it yet.
🤖 Generated with Claude Code