From f2cf552e8e4d141918b24678919c2dc189cc52cd Mon Sep 17 00:00:00 2001 From: Rob Parolin Date: Thu, 30 Jul 2026 13:56:46 -0700 Subject: [PATCH] ci: run pixi locked in the source-build workflow `ci-pixi-source-test.yml` used `setup-pixi` with `run-install: false` and plain `pixi run` everywhere, so nothing pinned CI to the committed lock files. If a `pixi.toml` changes without a matching `pixi lock`, pixi's default behaviour is to silently re-solve and rewrite `pixi.lock` in place -- CI then builds and tests an environment that is *not* the one committed to the repo, goes green, and the stale lock only surfaces for the next developer. Set `PIXI_LOCKED: "true"` at the workflow level so pixi aborts with "lock file not up-to-date with the workspace" instead. Why an env var rather than `--locked` on each command: the root test and docs tasks dispatch into the sub-package manifests via nested `pixi run --manifest-path ...`. A flag on the outer command does not reach those child processes; the environment variable does. Why `--locked` and not `pixi lock --check`: `--locked` compares the lock against the manifest only and does not re-solve against the channels, so it stays green when a floating dependency gets a new upstream release. `pixi lock --check` re-solves, and would go red spontaneously whenever conda-forge publishes -- `benchmarks/cuda_core` fails it today for exactly that reason (cuda-pathfinder 1.5.6 -> 1.6.0), with no change to its manifest. Verified locally: - `PIXI_LOCKED=true pixi run -e cu13 test-pathfinder` passes today (1095 passed, 4 skipped), including the nested manifest dispatch. - With a dependency added to `cuda_pathfinder/pixi.toml` and no re-lock, the same command fails fast with "lock file not up-to-date with the workspace"; without the variable, pixi re-solves and rewrites the lock. Co-Authored-By: Claude Opus 5 (1M context) --- .github/workflows/ci-pixi-source-test.yml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/.github/workflows/ci-pixi-source-test.yml b/.github/workflows/ci-pixi-source-test.yml index cdae1b0cf26..4bd9106a26f 100644 --- a/.github/workflows/ci-pixi-source-test.yml +++ b/.github/workflows/ci-pixi-source-test.yml @@ -58,6 +58,22 @@ env: # prefix-dev/pixi#6285 + #6123) also bumps the pixi.lock format to v7. PIXI_VERSION: "v0.73.0" + # Fail fast when a pixi.toml changed without a matching `pixi lock`, instead + # of silently re-solving. Without this, `pixi run` updates the lock file in + # place and CI tests an environment that is NOT the one committed to the + # repo -- so a stale lock passes CI and only breaks for the next developer. + # + # Set as an env var rather than a `--locked` flag on each command because the + # root test/docs tasks dispatch into the sub-package manifests via nested + # `pixi run --manifest-path ...`; the variable is inherited by those child + # processes, a flag on the outer command is not. + # + # `--locked` compares the lock against the manifest only. It does not re-solve + # against the channels, so it stays green when a floating dependency gets a + # new upstream release -- unlike `pixi lock --check`, which would go red + # spontaneously whenever conda-forge publishes. + PIXI_LOCKED: "true" + jobs: # ── PR guard: CPU-only build + import + placement smoke ── build-smoke: