Why do failing Hydra-builds end up in a release channel?

Help
1

Hi, I have a flake input nixpkgs/nixos-unstable which gets locked using nix flake update to the following commit:

"locked": {
  "lastModified": 1718318537,
  "narHash": "sha256-4Zu0RYRcAY/VWuu6awwq4opuiD//ahpc2aFHg2CWqFY=",
  "owner": "NixOS",
  "repo": "nixpkgs",
  "rev": "e9ee548d90ff586a6471b4ae80ae9cfcbceb3420",
  "type": "github"
}

This also reflects the status page which shows the same result:

image
image1083×52 7.53 KB

But when I check the Hydra build of this commit’s nixos:trunk-combined job, it shows up as having failed:
https://hydra.nixos.org/eval/1806989#tabs-inputs

Why would a revision that failed to build in Hydra be tagged as the latest of a release channel?

Might it be that nixos:trunk-combined doesn’t map to nixos-unstable? But from all jobsets this seems the most likely one.
Also, I started looking into this issue because when I try to build ungoogled-chromium on the above revision, nix doesn’t download any build cache but instead starts to build chromium locally. Looking at the associated Hydra build, it indeed failed.

2

Not every package is a channel blocker, so ungoogled-chromium doesn’t prevent channel advancement

1 Like
3

What is the rationale behind this non-inclusive list?

To me this means a release only guarantees that certain aspects of nixpkgs actually function. Is there a way to tell nix what aspects I consider important?

4

Right. It’d be an absurd burden to block on all 100k packages at all times, when some are higher priority than others, and some barely get used if at all.

You can set up your own build service if that’s what you mean, and then follow that output instead of the standard channels. Though I personally don’t need to update so often, so I’m fine waiting until build issues are resolved.

5

Right. It’d be an absurd burden to block on all 100k packages at all times, when some are higher priority than others, and some barely get used if at all.
True, ig that explains how you can keep a reasonable release cadence with such a scattered project. I wonder if a system where the last successful build of a package would be picked (with some restrictions), could improve the stability guarantees. That way temporarily broken / less maintained packages don’t block other higher priority / better maintained packages. Ofc nix currently isn’t at all designed to facilitate this.

You can set up your own build service
I would have hoped for a way to tell nix flake update to only update to the latest revision that meets certain side criteria (like a package building successfully). But looking at the nix flake input or the update command docs there doesn’t seem to be a way.