Every now and then, when I update my system configuration’s pin of nixpkgs (stable even!), I am surprised that one package or another stopped building (gscan2pdf in this example).
I understand that regressions on the stable channel are unavoidable (else they woudn’t happen, right), due to limited resources (I assume).
Still, it would be great to get some advance warning that something that I rely on is in a state of distress, so that I can maybe look into it myself.
It seems that there are already regular builds of many (all?) of the nixpkgs top-level packages, e.g. I found https://hydra.nixos.org/job/nixos/release-22.11/nixpkgs.gscan2pdf.x86_64-linux/all which shows that the package broke end of March.
- Is there a way to opt into a notification when specific packages fail?
- Is there a way to automatically derive the set of hydra jobs to keep an eye on from your NixOS configuration(s)?
3 Likes
This is a common desire. IIUC hydra technically has some capability here, but it’s disabled on hydra.nixos.org because it sends too many notifications.
Here’s an earlier thread: When hydra fails to build a package, does it notify maintainers?
The thread above has an example of a tool someone’s using to regularly build things they depend on in CI.
It might be possible to build something on top of the --dry-run flag to help identify paths you expect to fetch that want to download?
Maybe I should sign up for @samuela’s https://github.com/samuela/nixpkgs-upkeep until something more official comes along.
Would it be possible for community members to add custom hydra jobsets(?) (only cheap ones, like using linkFarm on a few nixpkgs outputs), and configure email notifications for these? It seems reasonable to use the official CI for a task like this, and not something independent.
nixpkgs-upkeep does not have an email solution at present. The current workflow is that it opens a GH Issue and tags relevant people. Would that be suitable for your use case? I would be open to PRs adding packages and cc’ing you on the relevant issues.
1 Like
Opening issues with me tagged is of course also good. It’s a a bit “louder” than a passive notification, and more suitable for packes where I have a particular role (maintainer, upstream). It would be somewhat weird if I’m tagged on an issue reporting that a generic, common tool (say, vim) no longer builds.