Use merge queue in nixpkgs

[Mic92]

We already deployed mergify in nixos-hardware: NixOS/nixos-hardware#1249 and in nix https://github.com/NixOS/nix/blob/master/.mergify.yml
This pull requests adds support for it in nixpkgs. Mergify adds support for declarative merge queues to nixpkgs. Merge queues make sure that pull request are tested against the latest base branch. The advantage over github's own merge queues is that, the configuration is part of the repository and therefore does not require a repository admin to keep "Required Checks" in sync with recently added CI checks.
Another advantage mergify has it's that it is a github app. There are many cases where github won't run checks on automated created pull requests. With mergify this is not an issue. If we are happy with the workflow introduced mergify, we can proceed adding it to CONTRIBUTING.md.
We have a similar feature in merge-bot. However it doesn't work very reliable. With mergify, we can later make merge-bot just add a label remove the complicated code and database integration we have just now.

[Mic92]

If mergify is ever deciding to shutdown on us, we can switch to https://github.com/rust-lang/bors for merge queues. At the moment this seems unlikely because it has a reasonable business model and supporting opensource projects is cheaper marketing compared to online advertisement. Bors is still in development at the time by the rust community and the infra team currently has other issues to solve.

[Mic92]

Another interesting optimization is that we could use merge queues to already compute output paths before the commits are merged into master. Currently we wait in pull request actions for evaluation in master. This is ok in most cases as the merge base is usually started a bit earlier than the github actions on a pull request, but with merge queues we could close this gap and also run actions less often as multiple pull requests are included in a single merge using batching.

[MattSturgeon]

Does mergify offer any features (useful to nixpkgs) that GitHub's native merge queue does not?

We've been using mergify on nixvim for a while, and while generally it's nice, it can be a little clunky at times; in ways that I suspect github's built-in solution may handle better.

EDIT:

The advantage over github's own merge queues is that, the configuration is part of the repository and therefore does not require a repository admin to keep "Required Checks" in sync with recently added CI checks.

[keysmashes]

would it be possible to create a "required checks are green" check (on: check_run or on: status, maybe), that is the only one actually monitored by the github "Required Checks" setting? then the configuration for "required" checks would effectively be part of the repository.

[Mic92]

@MattSturgeon the squash/rebase commands are nice and you can trigger "queue" commands based on label's i.e. have a backport be automatically merged. The latter one doesn't work github doesn't out-of-the box, because you need a github app token for that to be able to trigger github actions ci.

[Mic92]

would it be possible to create a "required checks are green" check (on: check_run or on: status, maybe), that is the only one actually monitored by the github "Required Checks" setting? then the configuration for "required" checks would effectively be part of the repository.

We have some checks that can soft-fail i.e. cherry-picks that are not the same as the original pull request: https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/check-cherry-picks.yml. We wouldn't be able to merge in this case.

[infinisil]

I'm fine with this as an experiment. We could enable this if others from @NixOS/org also agree, thoughts?

[infinisil]

NixOS/nixpkgs#364540 is a good example of something that would've been prevented with this

[infinisil]

@winterqt You 👎'd, can you give a reason?

[Mic92]

@winterqt You 👎'd, can you give a reason?

Ideally also an alternative.

[JohnRTitor]

Can we get this going? We can just run this as a beta test and always disable this if things go downhill.

[jtojnar]

If we enable it for testing while allowing manual merges through GitHub UI, how will it deal with those? I would expect them to invalidate the merge queue.