Use runners from namespace#19604
Closed
zanieb wants to merge 25 commits into
Closed
Conversation
zanieb
commented
May 29, 2026
| integration-test-windows-python-install-manager: | ||
| name: "windows python install manager" | ||
| timeout-minutes: 10 | ||
| # The Store package is not compatible with the Namespace Windows Server 2022 image. |
Member
Author
There was a problem hiding this comment.
Suggested change
| # The Store package is not compatible with the Namespace Windows Server 2022 image. | |
| # Note we cannot use Namespace's Windows runner here because ... |
zanieb
commented
May 29, 2026
Comment on lines
-79
to
-85
| - name: "Create minix filesystem (low hardlink limit)" | ||
| run: | | ||
| truncate -s 16M /tmp/minix.img | ||
| mkfs.minix /tmp/minix.img | ||
| sudo mkdir /minix | ||
| sudo mount -o loop /tmp/minix.img /minix | ||
| sudo chown "$(id -u):$(id -g)" /minix |
Member
Author
There was a problem hiding this comment.
We need to figure this out before merging
zanieb
commented
May 29, 2026
| hdiutil attach /tmp/noreflink.dmg | ||
| echo "HFS_MOUNT=/Volumes/NoReflink" >> "$GITHUB_ENV" | ||
|
|
||
| - name: "Create CI keychain" |
Member
Author
There was a problem hiding this comment.
Let's add a comment here explaining that we're creating an unlocked keychain
Member
Author
There was a problem hiding this comment.
which is not needed on GitHub or Depot runners, but is on Namespace
zanieb
commented
May 29, 2026
Comment on lines
+873
to
+875
| # run-on-arch installs binfmt handlers on local Docker, so bypass the Namespace Remote Builder for its tests. | ||
| - name: "Use local Docker builder for emulated tests" | ||
| run: docker buildx use default |
Member
Author
There was a problem hiding this comment.
Is this the best way to bypass this?
zanieb
commented
May 29, 2026
Comment on lines
+435
to
+453
| # Install the 32-bit cross target on 64-bit (noop if we're already on 64-bit) | ||
| rustup target add ${{ matrix.target }} | ||
| # If we're running on rhel centos, install needed packages. | ||
| if command -v yum &> /dev/null; then | ||
| yum update -y && yum install -y pkgconfig libatomic | ||
|
|
||
| # Install cross build requirements | ||
| if [[ "${{ matrix.target }}" == "i686-unknown-linux-gnu" ]]; then | ||
| yum install -y glibc-devel.i686 libstdc++-devel.i686 libatomic.i686 | ||
| fi | ||
|
|
||
| # Symlink libatomic so the linker can find it with -latomic. | ||
| if [[ -f "/usr/lib/libatomic.so.1" && ! -f "/usr/lib/libatomic.so" ]]; then | ||
| ln -s /usr/lib/libatomic.so.1 /usr/lib/libatomic.so | ||
| fi | ||
| else | ||
| # If we're running on debian-based system. | ||
| apt update -y && apt-get install -y pkg-config | ||
| fi |
Member
Author
There was a problem hiding this comment.
Let's put this in scripts/ instead?
zanieb
commented
May 29, 2026
Comment on lines
+429
to
+430
| # Match the uv wheel build above: i686 must cross-compile in a 64-bit container. | ||
| container: quay.io/pypa/manylinux2014 |
Member
Author
There was a problem hiding this comment.
Why did we not need this before?
zanieb
added a commit
that referenced
this pull request
May 29, 2026
As a part of #19604 I noticed that we were only testing WSL2 which is not usable on Windows 2022 which is still fairly common.
37169c7 to
7890577
Compare
The Linux cargo-test job failed before tests started when mounting the btrfs loop image: mount reported 'No such file or directory'. The Namespace runner executes inside a restricted container by default, which does not expose the mount capabilities required by the filesystem test setup. Request a privileged Namespace container for this job so its existing btrfs, tmpfs, and minix mount coverage can continue to run on Namespace.
The Namespace macOS cargo-test job reached the test suite but every native keyring write failed with Security.framework error -25308: 'User interaction is not allowed.' The non-interactive runner session does not start with an unlocked default user keychain. Create and unlock an ephemeral CI keychain, add it to the user search list, and make it the user-domain default before running the native-auth tests.
The Namespace Windows runner reached winget but the Microsoft Store package failed with 0x803fb104: 'The package is not compatible with the current Windows version or platform.' The expected WindowsApps py.exe shim was therefore never installed. Keep this Store-specific compatibility test on windows-latest while the rest of the Windows integration matrix continues to use Namespace.
The Namespace Windows runner executes jobs as LocalSystem. Vampire/setup-wsl reached wsl.exe, but WSL refused to install the distribution with WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED because WSL cannot run as LocalSystem. Keep this WSL-specific test on windows-latest while the remaining Windows jobs continue to use Namespace runners.
The Namespace Remote Builder does not share the runner-local binfmt registrations installed by uraimo/run-on-arch-action. The armv6 smoke test therefore failed with an exec format error, while the s390x smoke test failed inside remote QEMU during package installation. Select Docker's default local builder before the emulated wheel tests. This keeps release jobs on Namespace and retains Remote Builder caching for the preceding wheel builds while allowing the smoke-test action to use its local binfmt handlers.
The i686 uv-build wheel step let maturin select quay.io/pypa/manylinux2014_i686, but Namespace Docker rejected that image because it does not provide the requested linux/amd64 platform. The preceding uv wheel step already avoids this by cross-compiling i686 from the amd64 manylinux2014 image. Mirror the working container, target installation, cross dependencies, and compiler configuration in the uv-build wheel step.
The privileged Namespace runner can create loop devices, but its host kernel does not currently expose btrfs: mounting the image fails with 'unknown filesystem type btrfs'. Use an XFS loop filesystem formatted with reflink support instead. This keeps the Linux copy-on-write coverage enabled while allowing the cargo-test job to remain on Namespace.
The migrated Linux and macOS runner profiles now attach Namespace cache volumes with Git mirrors enabled. Standard checkout still clones from the remote for each job and cannot take advantage of those mirrors. Use Namespace's optimized checkout action on cache-enabled Namespace profiles. Keep standard checkout on GitHub-hosted, CodSpeed, mixed Windows, and uncached Namespace Windows jobs.
The migrated Linux and macOS profiles now attach Namespace cache volumes protected so only main can persist updates. Continuing to use Swatinem/rust-cache would retain the remote archive upload and download phases that the mounted volumes avoid. Use Namespace's Rust cache action on the five cache-enabled Linux and macOS jobs. Keep the existing cache action on Namespace Windows because cache volumes are not currently available there.
After the XFS reflink filesystem and tmpfs mount succeed, the Namespace host kernel rejects the low-hardlink minix image with 'unknown filesystem type minix'. Leave UV_INTERNAL__TEST_LOWLINKS_FS unset on Linux so the targeted hardlink-limit integration test skips while the rest of the Linux suite continues to run on Namespace. Windows keeps the NTFS low-hardlink coverage.
The Namespace Linux runner does not provide the implicit D-Bus session that the GitHub-hosted runner exposed. Starting gnome-keyring-daemon alone leaves the native-auth and uv-keyring tests failing with 'no secret service provider or dbus session found'. Start an explicit session bus before gnome-keyring and persist its address through GITHUB_ENV so the cargo test step can connect to the Secret Service provider.
The Namespace Windows runner previously started jobs as LocalSystem, causing the WSL integration test to fail with WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED. Namespace has rolled out a fix for how Windows sessions are started and expects it to resolve that failure.\n\nMove the WSL integration job back to the Namespace Windows profile so CI validates the updated session behavior.
Namespace's Windows session rollout resolves the previous WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED failure, but the runner still cannot create a WSL2 VM: setup-wsl fails with HCS_E_HYPERV_NOT_INSTALLED because the profile does not expose the required virtualization support.\n\nThe pyenv-win integration test exercises shim discovery from a Linux shell and does not depend on WSL2 behavior. Configure setup-wsl to use its supported WSL1 mode so the test can remain on Namespace Windows.
The walltime benchmark uploads a roughly 667 MB tar archive before handing it to the Codspeed runner. On Namespace, the GitHub artifact upload step took about 85 seconds. Disable zip compression for this upload so the next CI run can measure whether avoiding compression reduces the handoff overhead.
The Namespace Ampere ARM runner restored the walltime benchmark cache successfully but took roughly twice as long as Depot to compile the same crate set. Use the Apple M4 Pro-backed Linux ARM64 profile for this build so CI can compare the same 4 vCPU, 16 GB workload on the faster host class.
8844084 to
950590a
Compare
Namespace Windows runners can run the pyenv integration test with WSL1, but their profile still does not expose the virtualization support needed to create a WSL2 VM. The upstream workflow now exercises both WSL versions.\n\nKeep the WSL1 case on Namespace and retain the WSL2 case on GitHub-hosted Windows 2025 so the runner migration does not drop WSL2 coverage.
The Namespace cache action otherwise prefers a runner-provided spacectl binary and falls back to resolving the latest release. That makes the executable used by trusted CI mutable independently of the pinned action revision.\n\nPin spacectl 0.10.0 at each Namespace cache-action invocation so trusted builds use a reproducible CLI release.
The Namespace host kernel does not expose Minix, so the EMLINK recovery integration test skipped on Linux after the runner migration. Use an ext4 loop image instead; the test already exhausts ext4's approximately 65,000-link limit.
Document why the Store-backed Python Install Manager test remains on GitHub Windows and why Namespace macOS tests create an unlocked ephemeral keychain.
Namespace's Docker path requires linux/amd64 images, so the uv-build i686 wheel now mirrors the existing cross-compiled uv wheel. Move the shared container bootstrap into a script to keep the two release builds aligned.
run-on-arch installs binfmt handlers on runner-local Docker, while Namespace Remote Builders do not share them. Link Namespace's documented per-build opt-out next to each docker buildx use default step.
uv test inventory changesThis PR changes the tests when compared with the latest
|
Contributor
|
Values are medians across six
Windows jobs are substantially faster. macOS tests are modestly faster, while Linux tests, the simulated benchmark, and publish dry-run are slower. The ARM walltime benchmark itself is unchanged. Disabling artifact compression reduced upload time but increased the artifact from 667 MB to 1.89 GB and download time from 32–38 seconds to 1:18–1:55, making the overall transfer slower. One Namespace attempt waited 5:25 before Runs: The release matrix was excluded because the sampled |
zanieb
added a commit
that referenced
this pull request
Jun 9, 2026
Moves to equivalent Namspace runners for Windows instead of GitHub, which show the greatest performance improvement (picked out from #19604). These runners do not support persistent cache volumes in namespace and, unlike Depot, they do not hijack the `action/cache` API so we're still just using GitHub's caching model here alleviating any concerns about cache poisoning. Co-authored-by: Zanie Blue <contact@zanie.dev>
Member
Author
|
#19751 instead for now |
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
2 participants
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.
No description provided.