The vast majority of CI jobs to build the lib tests are caused by
changes in the maintainer list. In this case, we currently run the full
test-suite which takes 3-4 minutes. By moving the maintainers and teams
tests out of the test-with-nix file, we save almost all of that.
Building only those two tests on a change is almost instant. This only
works, because we previously enabled cachix for the workflow.
Note, that these tests are not actually run with both nix versions, even
though they were listed in the "test with specific nix version" file.
That's because we only differ in the nix version run *inside* the
sandbox, but not doing the outer build.
Since this file seems to be re-used by NixOS/nix' CI, this is
technically a small loss in coverage for that repo, but nixpkgs CI
considerations outweigh that. But because of this, I left the other
non-nix-version-specific tests in that file.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
The idea behind that is to enable users and developers of
downstream tools such as home-manager to test Nix master for several
reasons:
* Nix is currently trying to have a `master` branch that's always
releasable[1]. We're still on Nix 2.18 in nixpkgs due to too many
notable regressions. Enabling people to test latest master may help on
that end.
* This uses the most bleeding-edge Nix, but our packaging, so we can
identify issues with our packaging early.
* From what I've seen, most people are using the packages from nixpkgs
anyways instead of the upstream flake, this is far more convenient
anyways.
My plan is to update this once a week. Right now we rely on the
`installCheckPhase` here, but as soon as we have proper regression
testing[2], we may want to add `nixUnstable` there as well (however with
failures being allowed probably).
[1] https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204
[2] https://github.com/NixOS/nixpkgs/pull/304332
This commit temporarily adds pkgs/test/release to the
lib/tests/release.nix test suite, because ofborg already knows about
that entry point.
We should move the list of test entry points out of ofborg and into
a central place in nixpkgs:
https://github.com/NixOS/nixpkgs/issues/272591
Once we do that we won't need to have this ugly kludge in an
inappropriate place.
The aws-sdk-cpp tests are flaky.
Since pull requests to staging cause nix to be rebuilt, this means
that staging PRs end up getting false CI failures due to whatever is
flaky in the AWS SDK tests. Since none of our CI needs to (or
should be able to) contact AWS S3, let's just omit it all. Bonus:
the tests build way faster.
This makes bisecting nix a bit easier.
Example reproducer, invoked from nix directory:
```bash
nix-build ../nixpkgs/lib/tests/release.nix --arg nix '(builtins.getFlake "git+file://${toString ./.}").packages.x86_64-linux.default'
```
The old hard-coded lists are now used to test system parsing.
In the process, make an `assertTrue` in release lib for eval tests; also
use it in release-cross
