- Reference: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#staging
staging-nexthttps://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next+sort%3Acreated-desc
PRs merged into the staging branch are not immediately built by hydra.
They are manually batched and merged into staging-next for a mass hydra rebuild.
Therefore a commit in the middle of a staging branch may not enjoy any useful binary cache, at that time in the commit history.
To find a cached build we must go all the way to the branching point (either in its future or in its past).
As an example, let us consider:
- The suspect: NixOS/nixpkgs#246963
We would like to undo this commit.
However, it is merged into staging, so its parent may not (and indeed does not) have binary cache and will take forever to build!
To find a cached build:
This is not possible from the GitHub webui, but once we have a local checkout of nixpkgs, we can do:
rev=92e83bfab5d0dac17ed868fd1ba2118193597f42 ## pr NixOS/nixpkgs#246963
git log --reverse --ancestry-path --topo-order "$rev"^..masterThe --ancestry-path flag focuses onto the commits that connects "$rev"^ to master
and discard irrelevant branches.
We then scroll down towards the future and look for the next staging > staging-next > master merge.
This is:
- The
staging-nextmerge: NixOS/nixpkgs#248496
In order to undo the suspect NixOS/nixpkgs#246963 which comes from staging,
we can simply go to the parent NixOS/nixpkgs#249953
of the staging-next merge NixOS/nixpkgs#248496.
The price is that we also lose everything else that comes along the staging merge.
The same can be achieved with the Github webui, although it might be a bit convoluted.
In particular, git log --reverse "$rev"^..master can be achieved with a Github /compare,
but there is no way to specify --ancestry-path --topo-order so there might be some disordered or irrelevant commits.
Alternatively, we can go the other way around by checking the ancestors of the suspect, successively.
We are trying to find a commit that belongs to some PR which has been merged into master, not staging.
We find that:
is an automatic sync from the hydra built staging-next to staging. At some time in its future, it is manually merged back into staging-next and finally back into master, through NixOS/nixpkgs#248496. We've hences successfully located the staging-next merge as above.
Note that this merge point lies in the future of the suspect NixOS/nixpkgs#246963 of our interest, but it can be located by going to the past of our suspect.