600000 ms is deploy-pages' maximum, not its default - #42
Merged
Conversation
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.
The timeout raised in #41 never applied.
actions/deploy-pagesaccepts alarger value, warns, and clamps it straight back:
Confirmed against the action's own
action.yml:timeoutis documented as"default: 10 minutes", and 600000 turns out to be a ceiling as well as a default.
Both repositories then failed again at 10m10s and 10m07s with the larger value
set — which is the measurement that proves the input did nothing.
So a Pages deploy here can never wait longer than ten minutes, and nothing in
this repository widens that. The input is dropped; the comment stays, because
the obvious fix looks available and is not, and that is the part worth
someone's time.
What is actually wrong
Nothing in this repository. Every poll returns
deployment_queued, GitHubreported Pages fully operational throughout, and the same workflow shape
succeeded at 8m04s and 9m12s earlier the same day. The queue is simply slower
than the ceiling this afternoon.
install.mdfrom #39 is still unpublished for that reason. Merging thisprovides the new commit a fresh deployment needs — a re-run cannot, since the
cancelled deployment is keyed by SHA.
🤖 Generated with Claude Code