NixOS 21.05 ZERO Hydra Failures

Announcements
1

Hi everyone,

ZHF will be slightly different this year due to RFC 85. Most notable changes for contributors is that branch-off will be done on May 21st; so the first two weeks of ZHF don’t require backport PRs or commits (direct pushes are now discouraged so, we likely won’t see them again). This also means that there won’t be a beta for NixOS-21.05 until 21st as well.

Please visit the more detailed GitHub issue:
21.05 ZERO Hydra Failures

Let’s make 21.05 even more stable than 20.09 was! :partying_face: :

17 Likes
3

Is there any mechanism by which one can say, “I’m working on this?” That was my main frustration with last ZHF, working on something, opening a PR after searching for duplicates, then while my own PR is being reviewed a new PR being opened for the same thing and getting merged more quickly.

4 Likes
4

I wish I had a better answer, but not currently. If we did want some notion of “this is assigned to me”, then we would have to do something like github issues per package, and that’s not really feasible.

In the past we attempted to generate a VERY long checklist of packages, but that’s not easy to maintain, and only people with write access can actually update the checklist. Zero Hydra Failures: 19.09 edition · Issue #68361 · NixOS/nixpkgs · GitHub

2 Likes
5

Maybe just once you grab something open a draft PR? And in the instructions for ZHF emphasize searching for duplicates?

6 Likes
6

Or maybe I’m just more particular than most :stuck_out_tongue:.

7

I suspect if two people work on the same one by chance they will still learn something from each other and about the package.

2 Likes
8

Certainly possible, but only if they are aware of it.

9

I’ll add some notes about, searching for an existing PR, and if there is one open, then one should prefer to review it

1 Like
10

One idea might be to create a separate repo just for ZHF 21.05 issues, with one issue per package, and no other content – just issues. That way the github-issue tooling (“assigned to”, etc) would be available without the chaos of doing it all in the main nixpkgs repo.

11

This is my first ZHF and I have some questions.
Is it possible to do some more advanced filtering on the hydra jobs?
For example I’d like to see failing python packages for x86_64-linux. The hydra website doesn’t seem to accept wildcard or regex. It would also be nice if it only showed the jobs with failures in their own build, not in dependencies.

Are there in general any recommended tools to support the workflow around ZHF?

5 Likes
12

Not possible, I’m afraid. Naturally you can display all and then do whatever with the output; IIRC there’s API providing the same information.

Note: the dependencies sometimes do not have their own jobs, though that’s relatively rare I think. And in my opinion, the more failures a dependency causes, the more attention it should get.

13

Is there any way I can see which dependencies are blocking the most jobs?

14

AFAIK, the closest thing is: GitHub - nix-community/nix-review-tools: WIP tooling

I usually do:

mkdir tmp
cd tmp
../eval-report $EVAL_ID
xdg-open index.html

Should generate an html document ordered by failing builds.

EDIT: the reason to make a seperate directory is that it will cache build information in $PWD, and it will quickly clutter it with 1000s of build reports.

1 Like
15

Specifically? no.

Eventually I would like to make GitHub - jonringer/basinix: (WIP) Nix CI pull request review website into a polished review tool. Part of that would be carrying information about build status on different branches. Once I have a database of all the information, then I’m free to aggregate and present it many ways: failures for a maintainer, order by most downstream breakages, additonal filters by branch, etc.

4 Likes