NixOS 24.05 — Zero Hydra Failures

[wegank]

Hi, we are Weijia Wang & Jörg Thalheim, the release managers for NixOS 24.05 ("Uakari").

Today we want to invite everyone to participate in the Zero Hydra Failures Project, wherein we prepare the package set for the upcoming release, up until its public release at the end of May.

There are only two more upcoming dates that we'd like to mention in that context:

• 2024-05-22: Branch-off
• 2024-05-31: 24.05 Release

The complete timeline can be found in the

• NixOS 24.05 — Release Schedule #303285

The mission

Every time we plan to do a release, we take time to stabilize the master branch and, later on, the release branch.
Our goal here is to reduce the number of failing jobs on the nixpkgs:trunk nixos:trunk-combined jobsets as much as possible before branch-off. We call this the "Zero Hydra Failure" campaign.

Besides aiming for zero failed jobs, we also strive to again provide all packages that were available in the previous release.

Changes need to always target the master branch. Take note that the branch-off will occur on 2024-05-22, after which ZHF changes will need to be tagged with the backport: release-24.05 label to land in the stable release.

Jobsets

The relevant jobsets to check for failing jobs are:

• nixos:trunk-combined (Linux packages & NixOS tests)
• nixpkgs:trunk (Linux & Darwin packages)

Workflow

Finding broken packages

Eval reports

Evaluation reports provide a structural overview of the most impactful failing builds. They originated at https://github.com/nix-community/nix-review-tools and were automated over at https://github.com/malob/nix-review-tools-reports.

1. Navigate to https://malob.github.io/nix-review-tools-reports/.
2. Open the relevant jobset: see the previous section on which jobset to select based on what you are looking at (Linux, Darwin or NixOS tests).
3. Browse the latest reports for build failures.
   
4. Follow the links to the build failure on Hydra.

ZERO Hydra Failures

The platform automatically crawls Hydra, and lists packages by maintainer, and lists the most important dependencies (failing packages with the most dependents). It also graphs the general trend per platform.

1. Navigate to https://zh.fail.

For the record, we started ZHF here:

Latest Linux evaluation (completely built):     [1806101](https://hydra.nixos.org/eval/1806101) on 2024-05-05 12:20:15 (UTC)
Latest Darwin evaluation (completely built):    [1806102](https://hydra.nixos.org/eval/1806102) on 2024-05-05 12:41:48 (UTC)
Failing builds on aarch64-darwin:               1814
Failing builds on aarch64-linux:                1561
Failing builds on x86_64-darwin:                2043
Failing builds on x86_64-linux:                 1801
Total failed builds                             7219

For comparison, last release's ZHF started there:

Latest Linux evaluation (completely built):     [1801356](https://hydra.nixos.org/eval/1801356) on 2023-11-04 14:18:21 (UTC)
Latest Darwin evaluation (completely built):    [1801390](https://hydra.nixos.org/eval/1801390) on 2023-11-05 12:54:55 (UTC)
Failing builds on aarch64-darwin:               915
Failing builds on aarch64-linux:                1240
Failing builds on i686-linux:                   586
Failing builds on x86_64-darwin:                1142
Failing builds on x86_64-linux:                 1491
Total failed builds                             5374

Check on packages you maintain

1. Clone nixpkgs and checkout the master branch.

2. Run

   nix-build maintainers/scripts/build.nix --argstr maintainer <name>

Alternatively: you can check https://zh.fail/failed/overview.html also.

Hydra

Hydra is nixpkgs' CI platform, where all active branches are built and pushed into the cache, after which channels can originate from its build results.

1. Open the nixpkgs:trunk jobset.
2. Select the latest evaluation.
   
3. Directly failing jobs are marked with a red cross, while transitively failing ones are greyed out.
   
4. Use the search form to scope the package list to things relevant to you and that you can test.
   

Submit fixes

1. Search through PRs to make sure no one has provided a fix yet. If there is one, please take the time and help review the change.

2. If there is no open PR, troubleshoot why it's failing and fix it.

3. Create a pull request against the master branch, and wait for potential review and change requests.

   • Add the 0.kind: ZHF Fixes label, so people can better browse these fixes.
   • If your PR causes more than ~500 rebuilds, it is generally preferred to target staging to avoid compute churn for users on master.
   • If no reviewer is automatically added to your PR, check the Git history or the maintainers and ping them (in the pull request) or add them (if you have the rights) as reviewers.
   • If, after a while, no one has reviewed the PR, you can post it in the review requests room on Matrix or in the topic on Discourse to get more attention.
   • If, after an (extra) while, nothing really happened, you can drop a line in the NixOS development channel or mention @NixOS/nixos-release-managers on the PR.

Backporting

After 2024-05-22,

1. Apply the relevant backport label to land the fix in the release branch:

   • Changes to master get backported into release-24.05.
   • Changes to staging get backported into staging-24.05.

2. If the backport action fails, follow the manual backporting steps. Make sure to use git cherry-pick -x <rev> on all commits intended for backport.

   • @jonringer created a video covering the backport process.

---

Always link back to this issue by mentioning the issue number in the description of your pull request:

ZHF: #309482

If your PR receives no reviews or does not get merged, feel free to:

• Add the 0.kind: ZHF Fixes label, so people can better browse these fixes.
• Request or mention @NixOS/nixos-release-managers on the PR.

Broken packages

Everything we cannot fix in time will need to be marked broken on the respective platforms, so that Hydra will not retry builds over and over, thereby wasting compute resources.

Set meta.broken and add a reference and/or explanation, like this:

meta = {
  # ref to issue/explanation
  broken = stdenv.isDarwin; # only broken on darwin
  # broken = true; # broken on all platforms.
};

Orphaned packages

You can read about failing packages without a maintainer here: https://zh.fail/failed/by-maintainer/_.html (orphaned packages).

If you're new to NixOS, adopting an orphaned package is a great way to get involved and contribute to the community. By doing so, you'll not only help improve the overall quality of the NixOS ecosystem, but you'll also gain valuable experience working with Nix, the language and tool that powers the package management system.

By adopting an orphaned package, you'll be taking on a responsibility that can be both challenging and rewarding. You'll need to understand the package's code and dependencies, make sure it builds and works correctly, and respond to any issues or pull requests that come up. This process can be a great learning experience, as you'll be exposed to a wide variety of programming languages and libraries.

Moreover, by adopting an orphaned package, you'll be making a tangible impact on the NixOS community. Your contributions will be greatly appreciated by users who depend on that package, and you'll be helping to ensure that NixOS releases are as stable and up-to-date as possible.

Closing

This is a great way to help NixOS, and it is a great time for new contributors to start their nixpkgs adventure. 🥳

As with the feature freeze issue, please keep the discussion here to a minimum so we don't ping all maintainers (although relevant comments can of course be added here if they are directly ZHF-related) and ping one of the release managers (@wegank, @Mic92) in the respective issues.