|
| 1 | +# pixi-lock |
| 2 | + |
| 3 | +> [!NOTE] |
| 4 | +> This repo is likely to be moved to https://github.com/xarray-contrib |
| 5 | +
|
| 6 | +This repo provides two GitHub Actions for managing `pixi.lock` files with caching: |
| 7 | + |
| 8 | +- **`create-and-cache`**: Generates a `pixi.lock` file and caches it |
| 9 | +- **`restore`**: Restores the cached `pixi.lock` file in downstream jobs |
| 10 | + |
| 11 | +This two-action pattern is so that the lockfile can be omitted from the git |
| 12 | +history, but still be generated in a performant manner (i.e., regenerated |
| 13 | +and cached with a key that depends on `pixi.toml` and the date - |
| 14 | +then shared across jobs). |
| 15 | + |
| 16 | + |
| 17 | +## Usage |
| 18 | + |
| 19 | +```yaml |
| 20 | +jobs: |
| 21 | + cache-pixi-lock: |
| 22 | + runs-on: ubuntu-latest |
| 23 | + outputs: |
| 24 | + cache-key: ${{ steps.pixi-lock.outputs.cache-key }} |
| 25 | + pixi-version: ${{ steps.pixi-lock.outputs.pixi-version }} |
| 26 | + steps: |
| 27 | + - uses: actions/checkout@v4 |
| 28 | + - uses: Parcels-code/pixi-lock/create-and-cache@v1 |
| 29 | + id: pixi-lock |
| 30 | + with: |
| 31 | + pixi-version: ... # TODO: update with your selected pixi version |
| 32 | + |
| 33 | + ci: |
| 34 | + needs: cache-pixi-lock |
| 35 | + runs-on: ${{ matrix.os }} |
| 36 | + strategy: |
| 37 | + matrix: |
| 38 | + os: [ubuntu-latest, macos-latest, windows-latest] |
| 39 | + steps: |
| 40 | + - uses: actions/checkout@v4 |
| 41 | + - uses: Parcels-code/pixi-lock/restore@v1 |
| 42 | + with: |
| 43 | + cache-key: ${{ needs.cache-pixi-lock.outputs.cache-key }} |
| 44 | + - uses: prefix-dev/setup-pixi@v... # TODO: update with your selected setup-pixi version |
| 45 | + with: |
| 46 | + pixi-version: ${{ needs.cache-pixi-lock.outputs.pixi-version }} |
| 47 | + # ... your CI steps |
| 48 | +``` |
| 49 | + |
| 50 | +### Inputs & Outputs |
| 51 | + |
| 52 | +#### `create-and-cache` |
| 53 | + |
| 54 | +| Input | Description | Required | Default | |
| 55 | +|-------|-------------|----------|---------| |
| 56 | +| `pixi-version` | Version of pixi to use for generating the lock file | No | `latest` | |
| 57 | + |
| 58 | +| Output | Description | |
| 59 | +|--------|-------------| |
| 60 | +| `pixi-version` | The pixi version used | |
| 61 | +| `cache-key` | The cache key (includes today's date) | |
| 62 | + |
| 63 | +#### `restore` |
| 64 | + |
| 65 | +| Input | Description | Required | |
| 66 | +|-------|-------------|----------| |
| 67 | +| `cache-key` | The cache key from `create-and-cache` | Yes | |
| 68 | + |
| 69 | +> [!NOTE] |
| 70 | +> The cache key includes the current date, so the lock file is regenerated daily. |
| 71 | +> The fallback key (yesterday's date) is calculated automatically to handle edge cases where the restore job runs just after midnight. |
| 72 | +
|
| 73 | +## Why not commit the lock file? |
| 74 | + |
| 75 | +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. |
| 76 | + |
| 77 | +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. |
| 78 | + |
| 79 | +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. |
| 80 | + |
| 81 | + |
| 82 | +## Dev notes |
| 83 | + |
| 84 | +### Release checklist |
| 85 | + |
| 86 | +- Update the `README.md` bumping the version of action |
| 87 | +- Cut release |
0 commit comments