I want to optimise bisection workflows. Perhaps with some script even.
Currently, for any bisection over
nixpkgs, you usually quickly run into a commit that has a lot of dependencies involved, not built by hydra, because you get a staging-merge or end up on staging itself, due to the way how the bisection went.
So my idea was, to do a 2 pass bisection, to avoid the amount of necessary rebuilds.
In the first pass only consider commits that have been built by hydra and considered to be good enough to be a new channel push.
git bisect skip all the commits that are not.
In the second pass consider all the commits between the last known “good” and “bad” commits.
To be able to implement this though, I’d need such a list of commits that hydra created a new channel push from, is there an easy way to get such a list of commits? I think it would still be sufficient for my purposes, if this is only available for the last year of the unstable channels and the last 2 “full” release channels.
Does someone have an idea?
My current approach is to
nix eval some
outPaths of well known and expensive derivations, which in itself costs some time, extract the hashes, query
https://cache.nixos.org/$hash.narinfo for availability and skip if any of them is missing.
This list currently for me contains
rust in various versions, as well as systemd. I include the very same checks in every bisection I do from the start, ignoring whether an individual from this list would make sense, after python regularly surprised me with 3 LLVM rebuilds regularly because of some
I hope to cut a lot of the intermediate evals when I know in advance whether or not a commit has been built by hydra or not.