Skip to content

Raise deploy-pages' own timeout, not just the job's - #41

Merged
mbakalarski merged 1 commit into
mainfrom
fix-deploy-pages-action-timeout
Aug 6, 2026
Merged

Raise deploy-pages' own timeout, not just the job's#41
mbakalarski merged 1 commit into
mainfrom
fix-deploy-pages-action-timeout

Conversation

@mbakalarski

Copy link
Copy Markdown
Member

#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-pages has its own timeout input, default 600000 ms, and
polls the Pages backend until then:

Current status: deployment_queued      (repeatedly, for ten minutes)
##[error]Timeout reached, aborting!
Canceling Pages deployment...

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:

Created deployment for 4551916..., ID: 4551916...
##[error]Deployment cancelled.

Ten seconds, versus ten minutes the first time. So a merged docs change becomes
unpublishable until some new commit lands. install.md from #39 is in exactly
that state on main right 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 — and netclab.github.io measured 8m04s and
9m12s 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.yml needs the same input and does
not have it yet.

🤖 Generated with Claude Code

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
mbakalarski merged commit fcc6161 into main Aug 6, 2026
3 checks passed
@mbakalarski
mbakalarski deleted the fix-deploy-pages-action-timeout branch August 6, 2026 13:37
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant