ci(desktop): give the Windows desktop job headroom over its own spread (#10150)

Problem
The v1.38.7 release candidate (910afcd26) could not be tagged: its main-v2
push CI concluded `cancelled` because desktop-windows hit `timeout-minutes:
45` twice on the same SHA, at 45m00s and 45m16s. Every other job in that run
passed. `verify-release-push-ci.sh` requires a `success` conclusion, so the
release is blocked by the cap rather than by any product failure.

Root cause
45 sits inside the job's own duration spread, not above it. The five main-v2
push runs before the candidate took 34m43s, 35m20s, 41m33s, 34m56s and
42m56s — adjacent commits differ by more than seven minutes. The candidate
needs ~46m: both attempts show the same profile (step `test (Windows desktop
and update helper)` 17m, then `Build Windows installer and portable archive`
cut at 8.5m and 8.3m of the ~9m it needs). The job had been finishing under
the cap by margin, not by design, and the comment claiming "~25 minutes" was
stale.

Fix
Raise the job-level cap to 60 and record the measured range in the comment.
Every step inside the job keeps its own timeout (the two longest are capped
at 25 and 20 minutes), so a genuinely hung native step still fails fast and
cannot hold the concurrency group for the six-hour default.

Verification
- bash scripts/release-workflows.test.sh passes (stable release tag helper,
  cache impact, documentation impact, and release workflow contracts).
- The change is one job-level key; no step, matrix, trigger, or permission
  changed.
This commit is contained in:
SivanCola authored and GitHub committed 2026-09-12 00:18:54 +08:00
1 parent 910afcd269
commit 0c35021eb3
1 file changed
+3 -2
+3 -2
View File
@@ -736,8 +736,9 @@ jobs:
if: always() && (github.event_name != 'pull_request' || needs.changes.outputs.desktop != 'false')
runs-on: windows-latest
# A hung native step must not hold the workflow's concurrency group for the
# six-hour default. Normal runs finish in ~25 minutes.
timeout-minutes: 45
# six-hour default. main-v2 push runs measured 34-47 minutes on 2026-09-11,
# so 45 sat inside the job's own spread; every step keeps its own cap.
timeout-minutes: 60
defaults:
run:
shell: bash