Repository navigation
feat: change post-cleanup default to false - #272
Merged
Merged
Conversation
pavelzw
reviewed
Jun 29, 2026
Collaborator
|
i'm wondering whether we should also run the logout step always 🤔 wdyt? |
Hofer-Julian
force-pushed
the
push-plwrlppwovru
branch
from
June 29, 2026 09:09
f5b6f99 to
b9b18ef
Compare
Member
Author
Done! |
Member
Author
Yes, I think so. Let's do that in a follow-up PR though |
Especially on Windows this sometimes goes wrong. On other platforms it also often doesn't make sense since runners are ephemeral. Disabling that might even speed things up
Hofer-Julian
force-pushed
the
push-plwrlppwovru
branch
from
June 29, 2026 09:11
b9b18ef to
199e440
Compare
pavelzw
approved these changes
Jun 29, 2026
rerun-sync Bot
pushed a commit
to rerun-io/rerun
that referenced
this pull request
Jul 6, 2026
Bumps pixi from 0.55.0 (and one stale 0.39.5 pin in `check-sync-mode.yml`) to 0.71.3, and the `prefix-dev/setup-pixi` action from v0.9.4 to v0.10.0. We deliberately stop at 0.71.3 rather than the just-released 0.72.0, so we aren't on the bleeding edge and package managers (e.g. nixpkgs) have time to catch up. We use no 0.72-only features; 0.71.3 is the actual floor for this PR: rich platform entries landed in 0.71.0 (with fixes through 0.71.3), lock format v7 needs 0.68. > [!TIP] > **Review one commit at a time** — each commit is a self-contained change: > 1. **Update pixi to 0.72.0** — the version bump itself: CI pins, ghat, `requires-pixi`, docs, and the lock file format upgrade (the two big `pixi.lock` diffs are a mechanical v6 → v7 re-solve of the same locked packages). > 2. **Migrate deprecated `[system-requirements]` to platforms entries** — `dataplatform/pixi.toml` only, silences the deprecation warning. > 3. **Add `requires-pixi` to root `pixi.toml`** — one line, for consistency with the two subproject manifests. > 4. **Update setup-pixi action to v0.10.0** — all workflow pins, via `ghat update` + `ghat generate` for the ghat-managed ones. > 5. **Use pixi 0.71.3 instead of 0.72.0** — mechanical `0.72.0` → `0.71.3` in all the pins from commit 1, per review feedback. ### Updating pixi locally After this merges, `requires-pixi = ">=0.71.3"` means pixi will refuse to run with an older version. Update with: ```sh pixi self-update --version 0.71.3 # if installed via the install script (most common) brew upgrade pixi # if installed via Homebrew ``` Or reinstall from scratch: `curl -fsSL https://pixi.sh/install.sh | sh` Verify with `pixi --version`. Anything ≥ 0.71.3 works; note `rerun/scripts/check_env.py` expects exactly 0.71.3. ### Highlights since 0.55.0 Sixteen releases' worth of changes ([full changelog](https://github.com/prefix-dev/pixi/blob/main/CHANGELOG.md)); the ones most relevant to us: - **Lock file v7** (0.68) — more stable lock file contents (less churn), no machine-specific absolute paths, reproducible source builds. This PR includes the v6 → v7 upgrade for the root and dataplatform lock files. - **Rich platforms** (0.71) — platform entries can declare virtual packages like glibc/CUDA versions, replacing the now-deprecated `[system-requirements]` table (migrated for dataplatform in this PR). - **Multi-line tasks** (0.68, 0.70) — task `cmd` strings can span multiple lines natively in deno_task_shell, so long tasks no longer need `&&`-chains on one line. - **Task improvements** — `default-environment` per task (0.63), typed args with `choices` validation (0.65), `--` separator to pass extra args through to tasks (0.66). - **Registered workspaces** (0.66) — `pixi workspace register` once, then `pixi run -w <name> <task>` from anywhere, no `cd` or `--manifest-path` needed. Handy in a monorepo with three manifests. - **`exclude-newer`** (0.67) — can require a settle time (e.g. `exclude-newer = "14d"`) before new package versions are picked up, per workspace/channel/package. - **PEP 508 environment markers** for PyPI dependencies (0.63), and `[constraints]` to bound versions of packages you don't directly depend on (0.66). - **Faster/better UX** — parallel `pixi global update` (0.70), installation progress reporting (0.67), syntax-highlighted error reports (0.63), signed Windows binaries (0.65). - **Security** — fixes the high-severity "TARmageddon" vulnerability (CVE-2025-62518) in a tar dependency (0.59). - **Deprecations that affect us** — `[system-requirements]` → rich platforms (0.71, see above), and `pixi build` is deprecated in favor of `pixi publish` (0.68). ### setup-pixi v0.9.4 → v0.10.0 One breaking change: [`post-cleanup` now defaults to `false`](prefix-dev/setup-pixi#272) (the action no longer removes the pixi environment/binary/caches at job end). No workflow of ours sets `post-cleanup` explicitly, and all our runners (GitHub-hosted and RunsOn EC2) are ephemeral, so this is harmless — and skips pointless cleanup work at the end of every job. ### Changes - All `pixi-version:` pins in `.github/workflows/`, `rerun/.github/workflows/`, and `.github/actions/rerun/setup-wheel-test/action.yml` - All `prefix-dev/setup-pixi` action pins to v0.10.0 (ghat-managed workflows regenerated with `ghat update prefix-dev/setup-pixi && ghat generate`) - `PIXI_VERSION` in `.github/ghat/workflows/_common.ts`, with `generated_rerun_checks.yaml` updated to match (the `ghat check` CI job verifies it) - `requires-pixi = ">=0.71.3"` in all three manifests: `pixi.toml`, `rerun/pixi.toml`, and `dataplatform/pixi.toml` - `PIXI_VERSION` in `rerun/scripts/check_env.py` and the version note in `architecture/pixi_uv.md` - Root `pixi.lock` and `dataplatform/pixi.lock` auto-upgraded from lock format v6 to v7 (same locked packages, format-only re-solve). `rerun/pixi.lock` stays v6 — pixi considers it up-to-date as-is. - Migrated the deprecated `[system-requirements]` table in `dataplatform/pixi.toml` to per-platform virtual packages (`glibc = "2.31"` on the linux platform entries), silencing the deprecation warning. ### Not done: the same migration in `rerun/pixi.toml` `rerun/pixi.toml` still uses the deprecated `[system-requirements]` table (harmless warning). I attempted the same migration there, but pixi rejects virtual packages on standard-subdir platform entries in that manifest: ``` platform entry rejected: You tried to add a virtual package into a special subdir platform; either drop the virtual packages or give the entry a `name` distinct from its subdir ``` The identical syntax is accepted in `dataplatform/pixi.toml` — the difference seems to be that the rerun workspace defines features/environments. Working around it would require aliasing the platform names (e.g. `name = "linux-64-glibc228"`), which ripples into environment names and CI `--platform` flags — not worth it. Left as-is until pixi supports the migration cleanly. ### Verified - All three manifests parse and `pixi lock --check` passes against a real pixi 0.71.3 binary (only remaining warning: the known `[system-requirements]` deprecation in `rerun/pixi.toml`, see above). - `ghat generate` run with the real ghat binary (v0.9.0) reproduces the generated workflows byte-exact. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Source-Ref: ca6c813c0ca4a1cf68ac9ef12b57346e7050dba7 Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
znorgaard
added a commit
to fg-labs/nf-fgsv
that referenced
this pull request
Jul 30, 2026
Bump the pinned `setup-pixi` action and upgrade `pixi.lock` to the v7 format ## Changes **`prefix-dev/setup-pixi` v0.8.14 → v0.10.0** (`.github/workflows/docs.yml` ×2, `.github/workflows/nextflow_checks.yml` ×1), SHA-pinned as before. The only breaking change across that range is [`post-cleanup` defaulting to `false`](prefix-dev/setup-pixi#272). Both jobs run on ephemeral GitHub-hosted `ubuntu-latest` runners, which are discarded after the job, so skipping cleanup has no effect. (It would matter on self-hosted runners.) **`pixi.lock` format v6 → v7.** The diff is large (1,500 / 1,485) but contains **no dependency changes** — the re-solve reused the locked content. Verified by extracting every package URL from both sides: | | count | |---|---| | packages before | 164 | | packages after | 164 | | added-only | 0 | | removed-only | 0 | So the churn is format and ordering only. v7 adds an explicit `platforms:` block recording virtual packages (`__glibc`, `__osx`, `__archspec`) per platform, which is where the "improved reproducibility" comes from. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
MJohnson459
added a commit
to ClachDev/Mote
that referenced
this pull request
Jul 31, 2026
* CI: bump actions/checkout v4 -> v7 in the remaining workflows v4 targets Node 20, which the runner already force-upgrades to Node 24 with a deprecation warning on every run. The two image workflows were moved to v7 when they were written; build.yml and the two Claude workflows were left behind. None of the three uses pull_request_target or workflow_run, so v7's fork-checkout block does not apply. * CI: bump prefix-dev/setup-pixi v0.9.0 -> v0.10.0 Kept separate from the checkout bump because v0.10.0 flips the post-cleanup default to false (prefix-dev/setup-pixi#272), so a cache or build-time regression is attributable to one commit. The default flip is inert here. post-cleanup only deletes .pixi, the pixi binary and the rattler dirs at job end; both versions save the cache from the main step (main.ts), never the post step, so cleanup cannot race it, and these runners are ephemeral GitHub-hosted VMs that are destroyed anyway. Left at the new default rather than pinned back to true. Two real changes do land: the cache is now split into project and global entries, and the project key hashes the pixi binary as well as the lockfile. So the first build after this is a guaranteed cache miss, and subsequent pixi releases invalidate the cache (this repo does not pin a pixi version) -- correct, since a conda env built by a different pixi should not be reused.
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
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.
Especially on Windows this sometimes goes wrong.
On other platforms it also often doesn't make sense since runners are ephemeral. Disabling that might even speed things up
If updating documentation: