This nix-build action is an opinionated all-inclusive action that will
- Checkout your code
- Install a Nix language interpreter and daemon
- Setup artifacts caching
- Automatically run
nix-buildwith heuristics applied
Here's a simple sample to get you started:
name: "CI"
on:
pull_request:
push:
jobs:
build:
name: Build (${{ matrix.os }})
strategy:
fail-fast: false
matrix:
os:
- ubuntu-24.04
- macos-13 # most recent x86_64
- macos-15 # most recent aarch64
runs-on: ${{ matrix.os }}
steps:
- uses: samueldr/nix-build-action@latestNote
Prefer pinning to a released version, rather than following the latest branch.
This applies to all actions.
This sample will effectively run nix-build ./release.nix or nix-build ./default.nix at the root of your repository.
By default the artifacts will be sent to the cache, allowing future builds to resume from existing transitive builds (if relevant).
Heuristics is a big word for basically a small few options.
The first of the following files found will be nix-build't:
release.nixdefault.nix
*This mirrors an older, yet still relevant, convention with Nix projects, where the
default.nixmay expose a more involved API, and therelease.nixexpression is used as a well-known way to build the expected outputs.
There are a couple inputs you can provide to this action.
Be mindful about interactions between some inputs. Read the script and the action to better understand how they interact.
The expression file to build.
When missing, it will try in order: [ ./release.nix ./default.nix ].
Attributes to build from the expression.
When missing, it will follow the default Nix semantics around build outputs.
When provided, nix-build will pass the given value to the standard input, and build that instead of expression-file.
When provided, the call to nix-build will use these appended extra arguments.
Warning
Beware of string splitting semantics!
When provided, NIX_PATH will be set to this value.
Default: true
Whether the repository will be checked-out automatically with the actions/checkout action.
Use false to bring your own checkout action alternative.
Default: none
Space making action to use.
Supports the following: [ "none" "more-space-action" ].
Not enabled by default as it adds some time to the action runtime, while not always being necessary.
Default: lix-gha-installer-action
Installer action to use.
Supports the following: [ "lix-gha-installer-action" "none" ].
Use none to bring your own.
Default: none
Cache action to use.
Supports the following: [ "none" ].
Use none to disable or bring your own.
Default: 0
Setting this option to a numeric value other than zero enables waiting a random amount of time at the start of the action.
This is a common repeated pattern used to work around a thundering herd of github actions trampling over the API rate limits when dealing with multiple parallel builds, which may be exacerbated by using a matrix strategy.
Maybe!
As of right now, all steps (except building) are conditional.
If you don't want to use the actions/checkout to checkout your repo, set checkout-repo to false.
Similarly, all other actions are implemented as if they were an enum type, with the none value available to disable the step entirely.
Contributions welcome for alternative steps.
It is not supported at this moment, though a desired feature.
Contributions welcome to add support.
This is not a desired feature, as it involves knowing too much about the intended use-case.
Instead, you can safely add additional steps to upload artifacts to releases, just like you would otherwise.
Try making a matrix out of it,
and use the attributes input to build one attribute at a time.
This will also provide some parallelism, but unless done carefully, will not manage dependencies between attributes.
Currently unsupported, as I'm not using them myself. I don't think I could properly support the nuances of Flakes since I don't know them.
Contributions welcome to support Flakes appropriately.