Update README

Author: VeckoTheGecko

.github/workflows/test.yml

@@ -10,6 +10,9 @@ concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true
 
+env:
+  PIXI_VERSION: "v0.63.0"
+
 jobs:
   test:
     runs-on: ${{ matrix.os }}
@@ -32,6 +35,7 @@ jobs:
         uses: ./create-pixi-lock
         with:
           cache-frequency: ${{ matrix.cache-frequency }}
+          pixi-version: ${{ env.PIXI_VERSION }}$
 
       - name: Verify pixi.lock exists
         shell: bash
@@ -45,6 +49,9 @@ jobs:
 
       - name: Setup pixi and install environment
         uses: prefix-dev/setup-pixi@v0.9.3
+        with:
+          pixi-version: ${{ env.PIXI_VERSION }}$
+
 
       - name: Verify environment installed
         shell: bash

README.md

@@ -5,10 +5,47 @@
 
 This action creates a `pixi.lock` file and caches it for future use. Subsequent runs of this action on the same day restore the lock file instead of generating it anew.
 
+
+## Usage
+
+Basic usage with a set version of Pixi as well as daily cached lockfile:
+
+```yaml
+env:
+  PIXI_VERSION: "v0.63.0"
+
+# ...
+steps:
+  - uses: actions/checkout@v4
+
+  - uses: Parcels-code/create-pixi-lock@v1
+    with:
+      pixi-version: ${{ env.PIXI_VERSION }}$ # Default is latest
+      cache-frequency: daily # options are "daily", "weekly", "monthly". Default "daily"
+  - uses: prefix-dev/setup-pixi@v0.9.3
+    with:
+      pixi-version: ${{ env.PIXI_VERSION }}$
+```
+
+> [!NOTE]
+> Pinning your Pixi version in CI and updating this pin manually ensures better
+> Stability. Otherwise updates to Pixi which (a) change the format of the lock > file would break your CI for a period of `cache-frequency`, or (b) change the format of
+> `pixi.toml`, which would break your CI until you fix it.
+> This avoids any potentially breaking changes down the line (e.g., changes
+> in lock file behaviour
+
 ## Why not commit the lock file?
 
 Committing your lock file is considered good practice when working on application code. Providing fixed package versions results in perfect reproducibility of environments between machines, and hence also reproducibility of results.
 
 When developing and testing _library_ code, we don't want our environments to stay completely fixed - we want to test against environments covering a wide range of package versions to ensure compatability, including an environment includ the latest available versions of packages.
 
 The easiest way to test against the latest versions of packages - and avoid the noisy commit history (and additional overhead) of regularly updating a lock file in git - is instead to ignore the lock file and rely on developers and CI to generate their own lock files. This forgoes perfect reprodubility between developer machines, and with CI machines.
+
+
+## Dev notes
+
+### Release checklist
+
+- Update the `README.md` bumping the version of action
+- Cut release