Add create-pixi-lock action

[VeckoTheGecko]

See changes (including new README) for full details.

cc @keewis

[VeckoTheGecko]

Is there a concern with using prefix-dev/setup-pixi@v0.9.3 here - with knowledge that it will be called again in the users workflow later?

[VeckoTheGecko]

Pinning the version of Pixi for now. Thinking of making dependabot manage this - though that would come in a future PR

[VeckoTheGecko]

I do get an error

Run prefix-dev/setup-pixi@v0.9.3
  with:
    pixi-version: v0.63.0
  env:
    PIXI_VERSION: v0.63.0
Downloading Pixi
  Destination file path /Users/runner/.pixi/bin/pixi already exists
  Waiting 16 seconds before trying again
  Destination file path /Users/runner/.pixi/bin/pixi already exists
  Waiting 13 seconds before trying again

which to be honest I did expect - I didn't think setup-pixi would be idempotent .

Also I just saw

Since pixi is not yet stable, the API of this action may change between minor versions. Please pin the versions of this action to a specific version (i.e., prefix-dev/setup-pixi@v0.9.3) to avoid breaking changes.

in the README.md - making using setup-pixi two times like we do here less viable an option.

Is there a way that we can, in the lock generation, install pixi to a set location (unlikely to interfere with other things), generate the lock file, all while being cross platform?

[VeckoTheGecko]

generate the lock file, all while being cross platform?

Looking at the guts of setup-pixi https://github.com/prefix-dev/setup-pixi/blob/51b98037a96d8c8de9468a767400f984d173fd90/src/util.ts#L60-L71 - uhhhh, maybe not as simple as I hoped! 😅

[VeckoTheGecko]

And looks like Docker container actions are Linux only - that was going to be my next try 😭

https://docs.github.com/en/actions/concepts/workflows-and-actions/custom-actions#types-of-actions

Hopefully someone has more ideas

[keewis]

If I understand correctly, the action should:

• check for a existing valid cache, and skip the remaining steps in that case
• setup pixi
• run pixi lock
• create the cache for the lock file

What it could also do is to cache the used pixi version: as far as I can tell we don't actually need to pin pixi, we just need to make sure the pixi version does not change between the creation and the use of the lock file.

making using setup-pixi two times like we do here less viable an option.

Why would you even do that? As far as I can tell, the creation of the lock file should run in a separate job.

[keewis]

depending on how useful this is it might actually make sense to ask the pixi devs whether they would like to move it to the official pixi org

[VeckoTheGecko]

????? How is CI passing after updating the README?

[VeckoTheGecko]

So others also have context: We're currently having it run in a separate job via a workflow, which has quite ugly UI we want to simplify

diff --git .github/workflows/ci.yml .github/workflows/ci.yml
index 6ec127ed..48ac4734 100644
--- .github/workflows/ci.yml
+++ .github/workflows/ci.yml
@@ -1,164 +1,180 @@
 
+env:
+  PIXI_VERSION: "v0.63.0"
+
 jobs:
+  cache-pixi-lock:
+    uses: ./.github/workflows/cache-pixi-lock.yml
+    with:
+      pixi-version: "v0.62.2" # keep in sync with env var above
   unit-test:
     name: "Unit tests: ${{ matrix.os }} | pixi run -e ${{ matrix.pixi-environment }} tests"
     runs-on: ${{ matrix.os }}-latest
-    needs: []
+    needs: [cache-pixi-lock]
     env:
       COVERAGE_REPORT: "${{ matrix.os }}_${{ matrix.pixi-environment }}_unit_test_report.html"
     strategy:
       fail-fast: false
       matrix:
         os: [ubuntu, windows]
         pixi-environment: [test]
         include:
           - os: ubuntu
             pixi-environment: "test-py311"
           - os: ubuntu
             pixi-environment: "test-py313"
           - os: ubuntu
             pixi-environment: "test-minimum"
     steps:
       - uses: actions/checkout@v5
+      - name: Restore cached pixi lockfile
+        uses: actions/cache/restore@v4
+        id: restore-pixi-lock
+        with:
+          enableCrossOsArchive: true
+          path: |
+            pixi.lock
+          key: ${{ needs.cache-pixi-lock.outputs.cache-id }}
       - uses: prefix-dev/setup-pixi@v0.9.0
         with:
+          pixi-version: ${{ env.PIXI_VERSION }}
...

I'm now re-reading your comment pydata/xarray#10888 (comment) which suggests

cache-pixi-lock:
  needs: check-skip-ci
  steps:
   - uses: xarray-contrib/hypothetical-cache-pixi-lock/create@...

ci:
  needs: cache-pixi-lock
  matrix: ...
  steps:
   - uses: xarray-contrib/hypothetical-cache-and-create-pixi-lock/restore@...
   - run: |
       echo 'PIXI_VERSION=$(cat pixi_version)' >> GITHUB_ENV
   - uses: pixi-dev/setup-pixi@...
     with:
      pixi_version: ${{ env.PIXI_VERSION }}
  - ...

. I think this suggested pattern is probably better (also avoids race conditions between runs now to think of it...)

I'll open a new PR along those lines - sorry for the noise!

(though feel free to add any additional comments)

EDIT: typo

[keewis]

I was thinking of something like this:

jobs:
    cache-pixi-lock:
        runs-on: ubuntu-slim

        steps:
        - uses: actions/checkout@...
        - uses: Parcels-code/create-pixi-lock/cache@...

    ci:
        needs: cache-pixi-lock
        runs-on: ${{ matrix.os }}

        matrix:
            ...
        steps:
        - uses: actions/checkouts@...
        - uses: Parcels-code/create-pixi-lock/restore@...
        - uses: prefix-dev/setup-pixi@...
          with:
              pixi-version: ${{ needs.create-pixi-lock.outputs.pixi-version }}
        - ...
        

(not sure if the syntax is correct, though)

That way, we can avoid reusing a workflow, which feels quite clunky.

[VeckoTheGecko]

Superceded by #2