mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
ci: increase Windows release workflow timeouts (#20343)
## Why #20271 increased the `90`-minute timeout in `rust-release.yml`, but it did not update the reusable Windows workflow in `rust-release-windows.yml`. As a result, the Windows release compile jobs were still capped at `60` minutes and the `windows-x64` primary build could continue timing out. We are keeping the existing `90`-minute timeout in `rust-release.yml`. That increase was still directionally correct because the top-level release build benefits from extra headroom; the mistake was assuming it also covered the reusable Windows jobs. ## What Changed - increase the reusable Windows release workflow timeouts in `rust-release-windows.yml` from `60` minutes to `90` minutes - update the comment in `rust-release.yml` so it no longer implies that the top-level timeout covers the Windows reusable jobs
This commit is contained in:
committed by
GitHub
Unverified
parent
8f3c06cc97
commit
ae863e72a2
@@ -24,7 +24,9 @@ jobs:
|
||||
build-windows-binaries:
|
||||
name: Build Windows binaries - ${{ matrix.runner }} - ${{ matrix.target }} - ${{ matrix.bundle }}
|
||||
runs-on: ${{ matrix.runs_on }}
|
||||
timeout-minutes: 60
|
||||
# Windows release builds can exceed an hour on fat-LTO mainline releases,
|
||||
# so keep the timeout aligned with the top-level release build headroom.
|
||||
timeout-minutes: 90
|
||||
permissions:
|
||||
contents: read
|
||||
defaults:
|
||||
@@ -137,7 +139,7 @@ jobs:
|
||||
- build-windows-binaries
|
||||
name: Build - ${{ matrix.runner }} - ${{ matrix.target }}
|
||||
runs-on: ${{ matrix.runs_on }}
|
||||
timeout-minutes: 60
|
||||
timeout-minutes: 90
|
||||
permissions:
|
||||
contents: read
|
||||
id-token: write
|
||||
|
||||
@@ -49,9 +49,8 @@ jobs:
|
||||
needs: tag-check
|
||||
name: Build - ${{ matrix.runner }} - ${{ matrix.target }} - ${{ matrix.bundle }}
|
||||
runs-on: ${{ matrix.runs_on || matrix.runner }}
|
||||
# Codex binaries can take a long time to build, particularly on Windows.
|
||||
# Ideally, this would be 60 minutes, but let's add some headroom because
|
||||
# having to restart a release build due to a timeout is a major pain.
|
||||
# Release builds can take a long time, so leave some headroom to avoid
|
||||
# having to restart the full workflow due to a timeout.
|
||||
timeout-minutes: 90
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
Reference in New Issue
Block a user