prefix-dev
Post-job cleanup fails when setup-pixi action is invoked twice
See https://github.com/brendanjmeade/celeri/actions/runs/14402272022/job/40390461670?pr=141
The second cleanup fails with Error: ENOENT: no such file or directory, lstat '/home/runner/.pixi/bin/pixi'. I would have expected cleanup to be idempotent.
# Don't install the environment yet.
# We first check the lockfile explicitly in a separate step.
- uses: prefix-dev/[email protected]
with:
cache: false
run-install: false
- name: Check if pixi lockfile is up-to-date
run: pixi list --locked
# Now install the environment.
- uses: prefix-dev/[email protected]
with:
cache: true
environments: ${{ matrix.pixi-environment }}
could you explain to me the reasoning why you invoke setup-pixi twice? the "check if pixi lockfile is up-to-date" step is already implicitly done by setup-pixi see https://github.com/prefix-dev/setup-pixi#--frozen-and---locked:
If you don't specify anything, the default behavior is to run pixi install --locked if a pixi.lock file is present and pixi install otherwise.
Hey, ya, perhaps the real underlying issue is that the error reporting is far from ideal. Take for example this run. https://github.com/brendanjmeade/celeri/actions/runs/14400087567
Here's my UX:
Big scary lots of red, exit code 1, sky is falling, no indication why. So click...
Click again...
And yet again...
IMHO I shouldn't have to go this deeply in order to find such an obvious cause. Thus I use another job explicitly named for checking that the lockfile is up-to-date so I can see immediately. (So much red really dampens the mood. 😉) Any ideas about how to improve this?
maybe a mode in pixi that indicates we are in GHA makes sense where error messages are prefixed with ::error:: (and maybe warnings with ::warning::) would probably be better imo, see also https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-error-message
either pixi looks at $GITHUB_ACTIONS or we set a custom $PIXI_GITHUB_ACTIONS env variable (i would be in favor of the former). rattler-build already has something similar