From a9e350c15843405bcd93db8db6ef395eac802f9f Mon Sep 17 00:00:00 2001 From: Xuanwo Date: Thu, 24 Sep 2026 01:04:18 +0800 Subject: [PATCH] ci(python): build Windows release wheel on 8-core runner (#4264) Since #4241 restored fat LTO / 1 codegen unit for the Windows wheel, the `windows` job in PyPI Publish has been cancelled at its 90-minute timeout on every run, including the v0.40.0-beta.6 and v0.40.0-beta.7 tags, so neither release was published. In those runs dependency compilation finishes after ~26 minutes and the `lancedb` crate compile + fat-LTO step was still running after 63 minutes. Move the job to the org's `windows-2025-8x-x64` larger runner and raise the timeout to 150 minutes. Fat LTO stays, since the thin-LTO wheel exceeds PyPI's 100 MiB limit. The final fat-LTO step is largely single-threaded, so the gain from 8 cores is mainly in the parallel dependency phase plus faster/larger hardware; the PR run of this workflow is the first measurement of fat LTO on this runner. --- .github/workflows/pypi-publish.yml | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/.github/workflows/pypi-publish.yml b/.github/workflows/pypi-publish.yml index 5f45ba68c..4f883aec1 100644 --- a/.github/workflows/pypi-publish.yml +++ b/.github/workflows/pypi-publish.yml @@ -21,7 +21,7 @@ permissions: contents: read # Without this, a force-push to a PR leaves the previous run going -- including -# a ~74 minute Windows job and a billed arm64 wheel build. +# a long fat-LTO Windows job and a billed arm64 wheel build. concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: true @@ -123,8 +123,11 @@ jobs: path: target/wheels/lancedb-*.whl if-no-files-found: error windows: - timeout-minutes: 90 - runs-on: windows-latest + # The fat-LTO build of the `lancedb` crate does not finish within 90 minutes + # on the 4-core standard runner, so use the 8-core larger runner with extra + # headroom. + timeout-minutes: 150 + runs-on: windows-2025-8x-x64 env: # link.exe is single-threaded and the long pole on Windows builds. Use # rustc's bundled lld-link instead. @@ -145,7 +148,7 @@ jobs: # or the default branch -- so with no run on main there is nothing that # can populate an entry the release build would be allowed to read. Fixing # this needs a main/nightly trigger (which would also catch wheel-build - # breakage before a release); the ~74 minutes here is otherwise dominated + # breakage before a release); the build time here is otherwise dominated # by the fat-LTO link, which no cache avoids. - uses: ./.github/workflows/build_windows_wheel with: