Advance channels with merge commits
Opened this issue · 6 comments
If you have a history composed of merge commits as the mainline, like something like https://github.com/lf-/necktangler/, you can then git bisect --first-parent and natively get bisects of actual builds of the channel.
This is pretty easy to implement in the channel scripts as it's just a funny git merge. Possibly needs git commit-tree as I think git merge -s theirs doesn't exist and we want the first parent to be the last merge commit.
@edef1c notes that this likely cannot be done on the current main channel branch as it will break "all commits on a channel appear in that channel's release branch". So this would probably have to be done on a separate branch, or in combination with a branch name reorganization that would break it anyway.
In our discussion we realised that we actually could do this really nicely if we combined the restructuring with a name change: e.g. channel/25.05/nixos-small. This would ensure no existing consumers are broken, that we could deliver this at any time in the cycle while also having a space to backfill old ones, and that we separate out automatically managed branches from ones that humans use.
Why do you want this kind of git bisect --first-parent? I think it's better to do the same on the underlying branch (master / release-*). Missing binaries should be relatively rare on those commits, and you get pointed to a particular pull request, though it might be a staging-next* PR, of course.
The reason to do this is the same reason that hydrasect exists: to not deal with commits that don't have 100% of things built, and yes this does regularly happen: I recently accidentally had my desktop system running nixos-unstable-small and found myself rebuilding KDE. It makes your bisects immensely faster if you can just deal with commits with full binaries. This branch structure is just hydrasect except that it actually exists (since that required infra run by Graham that's since dead), doesn't require any third party tooling, and can provide extra metadata like direct links to the hydra build.
The other reason is that it's helpful to be able to find out what the channel bumps are in general even if you're not bisecting; for example, to revert to the last channel bump if something broke, without having to fight a death match with the Hydra UI.
I also think there's a discoverability value: if the commits are obviously automated looking, they tempt new people to click on them and find out where they came from, so this provides a tiny learning opportunity on how the CI works.
OK-ish, thoughnixos-unstable-small is a different case. (you're too early there, and most of the binaries should appear within a couple days)
For bisecting I'm mainly missing completely a different thing: negative cache (even a local one). Especially towards the end, you end up rebuilding the same failing thing (same .drv), if you go with a straightforward approach.
Either way, the proposal makes sense to me, even if it isn't without tiny down-sides.
It could be like
git checkout nixos-unstable
git merge --no-ff $master_commit_of_the_hydra_eval \
-m 'something sensible + link to the Hydra eval'
git pushYes, though I would be inclined to use git commit-tree when making the commit to make absolutely sure that the tree is identical to the second parent.