Since https://github.com/NixOS/nixpkgs/pull/281374, the
nixpkgs-check-by-name tooling is pinned to a specific /nix/store path to
avoid having to evaluate Nixpkgs in CI.
The same path is used for local runs, but that doesn't actually work
when you're trying to run it on a platform different from CI.
This commit makes it work by being clearer about platforms and making
local runs check out the correct Nixpkgs to evaluate the tool from.
Before this, the tool for CI would update when nixos-unstable updated,
which is kind of terrible because you don't know when it happens, and it
might break master.
In fact, the tooling _right now_ has a serious bug and shouldn't be used!
This PR addresses this by _pinning_ the tooling in Nixpkgs itself.
Updating the tooling now requires two PRs:
- The first PR to update the tooling source
- (wait for Hydra to build and publish it in nixos-unstable)
- The second PR to update the pinned tooling
In turn you know exactly when the changes are going to take effect.
This change however has additional benefits:
- It makes CI more reproducible, because it doesn't depend on the state
of nixos-unstable anymore
- Updates to the tooling can be tested with the workflow itself,
because PRs that update the pinned tool will be tested on the updated
version
- CI gets a sizable speed boost, because there's no need to download and
evaluate a channel anymore
- It makes it more realistic to move the source of the tool into a
separate repository
- It removes the brittle branch-specific logic that was previously
needed to ensure that release branches use their own version of the
tooling.
Given the prior attempts to encourage Nix package bumps to be more stable, we failed, failed and failed again.
Today again, we shipped a broken Nix (2.19.2) without sufficient testing to unstable-small and it broke some users.
As announced in the past, I am taking ownership of the package manager bumps and modifications
as seemingly no one is interested to do it inside of Nixpkgs.
Now that we have a script to run the check locally,
there's no real need to output the information to reproduce anymore,
which allows cleaning up the CI workflow.
Furthermore, this prepares the CI workflow to be passed `--base`, as
introduced recently.
Where this was a markdown heading, it sometimes had the wrong weight
so it appeared as if it was a subheading of the previous section, and
some people feel the word "Priorities" creates misleading
expectations.
Link: https://github.com/NixOS/nixpkgs/pull/203969/files#r1037761779
For reproducibility.
Command:
```shell
for file in .github/workflows/*.y*ml; do
npx pin-github-action --comment=' {ref}' "$file"
done
```
Then had to manually replace all the versions with accurate specifiers
(for example, "v4" → "v4.1.1" in case of `actions/checkout`).
We've had a recent PR CI mass failure event, ultimately caused by the
mergeability check GitHub API not returning a result.
But due to the `pkgs/by-name` check workflow not backing off
appropriately between retries, it pummeled the API, resulting in
exceeding the API rate limit:
https://github.com/NixOS/nixpkgs/actions/runs/7010089143/job/19069845070
This commit fixes that for the future by implementing a retry strategy limited to three
retries, with exponential backoff
This re-introduces the old stable ZFS version we had in the past following
the many predicted issues of ZFS 2.2.x series, that is much more stable
than any further ZFS version at the moment.
I am also removing myself from maintenance of any further ZFS versions as I am
planning to quit ZFS maintenance at some point.
In the meantime, for users like me who depend on ZFS for critical operations, here is a ZFS version
that is known to work for LTS kernels.
