workflows/periodic-merge: merge merge-base into haskell-updates

[sternenseemann]

Since haskell-updates is based on master, but merges into staging, we need to merge in a merge-base of staging and master. See #361143.

I'm a bit worried that the information GitHub uses for displaying Pull-Requests becomes stale and this will “add” commits to the PR compared to the base anyways. We'll find out, I suppose.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[vcunat]

I don't share the worry. This point is the same as in the current staging-* pull requests, isn't it?

[sternenseemann]

@vcunat It should be fine, I agree. I had some problems with the current PR, but maybe that was mostly cases of the base reference not updating when staging was pushed when haskell-updates was already ahead which should never happen with this.

[sternenseemann]

I've tested this on my fork (by removing the if).

• Successful run: https://github.com/sternenseemann/nixpkgs/actions/runs/12480537165/job/34831522582
• Created merge commit: sternenseemann@a5e5cf0

Unfortunately, the workflow is pretty slow since it has to do a full fetch of nixpkgs. I don't think we can get the merge base via the GitHub API, unfortunately.

[vcunat]

We had lots of merge conflicts in this staging-next iteration. And even without them I'm not sure about the order of processing in these automatic merges.

[maralorn]

LGTM, any reasons not to merge this rn?

[sternenseemann]

Successful run with the latest version of the PR: https://github.com/sternenseemann/nixpkgs/actions/runs/12505278130/job/34888392237

[sternenseemann]

Solved merge conflicts, run successful: https://github.com/sternenseemann/nixpkgs/actions/runs/12583297518/job/35070543436

[github-actions]

Periodic merge from 8f3e1f807051e32d8c95cd12b9b421623850a34d into haskell-updates has failed.

[sternenseemann]

Seems like my fear were warranted. The workflow merged e554bf1 into haskell-updates which is an ancestor of staging at the time of the merge (eb439c0). Despite that, the GitHub UI adds a ton of commits to the PR view (#371032, edit: I've since reset the UI so it may no longer be visible, but will surely happen again).

I know that you can fix this by opening the base branch dropdown menu and selecting the same target branch again. I must say I don't really understand why this is a problem in this situation, but wasn't a problem when we'd target master and merge the current HEAD of master into haskell-updates. Why does GitHub update the head of the base branch for the comparison in one case, but not in the other?

[sternenseemann]

The only difference between the two situations I've outlined above I could think of is that the merge commit merging haskell-updates into master would be part of the branch going forward (or at least as soon as master would be merged into haskell-updates again). With the current situation this only happens after the merge commit goes from staging to staging-next to master and via the merge workflows to staging-next and then to staging, so it is part of the merge-base of haskell-updates and staging.

This definitely causes that the branch always shows up as conflicting with staging since staging is always ahead by the merge conflict that also touches all the files haskell-updates does. This is not a problem in practice, you just have to merge manually and git will be able to solve all “conflicts” automatically.

It seems like the likeliest explanation for the UI glitch on GitHub, but I'm also not quite sure. That you can get the UI out of this bad state shows that it doesn't have to be this way. It is hard to know what GitHub caches internally to cause this problem…