This works around GitHub's limit on the number of matrix jobs (fixes
#947), by running all builds in a single job. To maintain some speed, we
use `nix-fast-build`, which uses multiple cores for evaluation, and skips
any builds for which the final derivation is already in a binary cache.
Although this makes the run for an individual pull request slower, the
amount of duplicated work is greatly reduced: previously, we often had
100 machines building the same derivation in parallel. This means that
more runners are available should there be multiple pull requests opened
in a short space of time, so there is less queuing. It's also more
energy efficient.
A potential downside is that the logs are all merged together, so it can
be hard to find what failed when lots of outputs were built.
`nix-fast-build` does report a list of failed attributes at the end of
the log, but this is currently broken:
https://github.com/Mic92/nix-fast-build/pull/98
The script used to launch `nix-fast-build` is also added to the
developer shell for local use. This replaces the old `nix-flake-check`
package (closes#898).
I also saw the opportunity to enable checks on `aarch64-linux` and
`aarch64-darwin` - as these are available as GitHub hosted runners.
This commit allows CI jobs to degrade gracefully if Cachix has issues,
by skipping uploads and/or building packages from scratch rather than
failing the job.
This is in response to the recent failures on `master`, which appear to
be caused by a 502 (Bad Gateway) response while uploading some of the
build results.
This will improve CI performance, and may also be used locally,
although this is not officially documented at this time.
I tested the required amount of space by building a `pkgs.linkFarm`
containing all testbeds, then manually pushing this to an empty Cachix
cache.
The total space used was 274 MiB of the 5 GiB free allowance, so
Cachix is good enough to cache at least 20 commits of history,
assuming the worst case scenario of every commit changing
every derivation we build.
Fixes#880
Optionalize the stylix.image option when stylix.base16Scheme is set,
making the following Stylix configurations valid:
[
// Now it possible to set 'stylix.image = null', if
// stylix.base16Scheme is set.
{
base16Scheme = /* ... */;
}
// This configuration was already possible.
{
image = /* ... */;
}
// This configuration was already possible.
{
base16Scheme = /* ... */;
image = /* ... */;
}
]
Closes: https://github.com/danth/stylix/issues/200
Closes: https://github.com/danth/stylix/issues/442
Link: https://github.com/danth/stylix/pull/717
Co-authored-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Reviewed-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Tested-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Reviewed-by: Daniel Thwaites <danth@danth.me>
Make the get-derivations job fail when the command writing to the
$GITHUB_OUTPUT file fails.
Previously, the $GITHUB_OUTPUT file was successfully created when the
input command failed, resulting in an empty $GITHUB_OUTPUT file. [1]
[1]: https://stackoverflow.com/questions/59287865
Disable IFD in the CI to prevent regressions mentioned in commit
e72aa84da1 ("{vencord,vesktop}: revert attempt to support fonts
(#844)").
Link: https://github.com/danth/stylix/pull/855
Reviewed-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Run the CI on PRs, while preventing it from running twice for non-fork
PRs by limiting the push event to protected branches. [1]
This restores the workflow trigger that was accidentally modified in
commit 2b85a56235 ("ci: simplify workflows").
[1]: https://github.com/danth/stylix/pull/749#issuecomment-2573437938
Prevent the Check workflow from running duplicated checks outputs.
The jq query should now be faster and arguably more readable.
Link: https://github.com/danth/stylix/pull/519
Consolidate the separate Build and Lint workflows into a unified Check
workflow, as linting is now integrated into the build process.
Link: https://github.com/danth/stylix/pull/519
Prevent some unexpected flake.nix and flock.lock revision
inconsistencies by building configurations with the
--no-update-lock-file option:
> --no-update-lock-file
>
> Do not allow any updates to the flake's lock file.
>
> -- nix3-build(1)
Link: https://github.com/danth/stylix/pull/674
Reviewed-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
This is heavily based on the workflow used by Nixpkgs.
It allows us to automatically create backport pull requests by labelling
the original pull request.
Labels should use the format `backport «branch»`.
