GitHub Action to set up the pixi package manager.

- uses: pavelzw/[email protected]
  with:
    pixi-version: '0.2.0'
    cache: true
    auth-host: prefix.dev
    auth-token: ${{ secrets.PREFIX_DEV_TOKEN }}
- run: pixi run test

To see all available input arguments, see the action.yml file.

The action supports caching of the pixi environment. To enable caching, set cache: true. It will then use the pixi.lock file to generate a hash of the environment and cache it. If the cache is hit, the action will skip the installation and use the cached environment.

If you need to customize your cache-key, you can use the cache-key input argument. This will be the prefix of the cache key. The full cache key will be <cache-key><conda-arch>-<hash>.

There are currently three ways to authenticate with pixi:

• using a token
• using a username and password
• using a conda-token

For more information, see the pixi documentation.

Specify the token using the auth-token input argument. This form of authentication (bearer token in the request headers) is mainly used at prefix.dev.

- uses: pavelzw/[email protected]
  with:
    auth-host: prefix.dev
    auth-token: ${{ secrets.PREFIX_DEV_TOKEN }}

Specify the username and password using the auth-username and auth-password input arguments. This form of authentication (HTTP Basic Auth) is used in some enterprise environments with artifactory for example.

- uses: pavelzw/[email protected]
  with:
    auth-host: custom-artifactory.com
    auth-username: ${{ secrets.PIXI_USERNAME }}
    auth-password: ${{ secrets.PIXI_PASSWORD }}

Specify the conda-token using the conda-token input argument. This form of authentication (token is encoded in URL: https://my-quetz-instance.com/t/<token>/get/custom-channel) is used at anaconda.org or with quetz instances.

- uses: pavelzw/[email protected]
  with:
    auth-host: anaconda.org # or my-quetz-instance.com
    conda-token: ${{ secrets.CONDA_TOKEN }}

setup-pixi allows you to run command inside of the pixi environment by specifying a custom shell wrapper with shell: pixi run bash {0}. This can be useful if you want to run commands inside of the pixi environment, but don't want to use the pixi run command for each command.

- run: | # everything here will be run inside of the pixi environment
    python --version
    pip install -e --no-deps .
  shell: pixi run bash {0}

You can even run python scripts like this:

- run: | # everything here will be run inside of the pixi environment
    import my_package
    print("Hello world!")
  shell: pixi run python {0}

There are two types of debug logging that you can enable.

The first one is the debug logging of the action itself. This can be enabled by running the action with the RUNNER_DEBUG environment variable set to true.

- uses: pavelzw/[email protected]
  env:
    RUNNER_DEBUG: true

Alternatively, you can enable debug logging for the action by re-running the action in debug mode:

For more information about debug logging in GitHub Actions, see the official documentation.

The second type is the debug logging of the pixi executable. This can be specified by setting the log-level input.

- uses: pavelzw/[email protected]
  with:
    # one of `q`, `default`, `v`, `vv`, or `vvv`.
    log-level: vvv

If nothing is specified, setup-pixi will default to default or vv depending on if debug logging is enabled for the action.

On self hosted runners, it may happen that some files are persisted between jobs. This can lead to problems or secrets getting leaked between job runs. To avoid this, you can use the post-cleanup input to specify the post cleanup behavior of the action (i.e., what happens after all your commands have been executed).

If you set post-cleanup to true, the action will delete the following files:

• .pixi environment
• the pixi binary
• the rattler cache
• other rattler files in ~/.rattler

If nothing is specified, setup-pixi will default to true.

- uses: pavelzw/[email protected]
  with:
    post-cleanup: false

If you want to see more examples, you can take a look at the GitHub Workflows of this repository.

1. Clone this repository.
2. Run pnpm install inside the repository (if you don't have pnpm installed, you can install it with npm install -g pnpm or brew install pnpm).
3. Run pnpm dev for live transpilation of the TypeScript source code.
4. To test the action, you can run act (inside docker) or use ✨ CI driven development ✨.