App for Nixpkgs backports

[infinisil]

CI currently doesn't get triggered for the automated Nixpkgs backports, e.g. see NixOS/nixpkgs#360258. This happens because the PR is created by the default GitHub Actions bot account, which has some built-in infinite recursion prevention measures.

We can fix this by using a separate GitHub App bot account instead. This is a dependency for NixOS/nixpkgs#360260.

Instructions for @NixOS/org:

• Create new App (direct link)
  • Name: Nix Backports
  • Homepage URL: https://github.com/NixOS/nixpkgs
  • Disable Webhooks
  • Permissions:
    • Repository > Contents: read-write (to create the backport branch)
    • Repository > Pull Requests: read-write (to create the backport PR)
• Install the App on the NixOS, give it access to only https://github.com/nixos/nixpkgs
• Set the App ID as a new repository variable (direct link) named BACKPORT_APP_ID
• Generate a private key for the App and set it as a new repository secret (direct link) named BACKPORT_PRIVATE_KEY

[roberth]

For NixOS/nix, @Mic92 has set up mergify. This solves the GHA recursion prevention problem, and could save us from reinventing the wheel. I think installing that GitHub App does not create any disruption before its config file is added to the repo (or after, if handled with care), but I'd like to confirm that. @Mic92 wdyt?

[infinisil]

I think for now it would be easiest to just add the tightly-scoped GitHub app, it doesn't take much to make use of it: NixOS/nixpkgs#360260

[Mic92]

I am ok either way. Can we have mergify as well? It has commands to rebase/squash pull requests and also the merge queue feature is neat (heavily used in nixos-hardware) to make sure main is always green.

[winterqt]

I'd rather have everyone use Mergify (or GH merge trains) since we now can actually reliably (and quickly!) report on eval status. I don't think we should add Mergify to Nixpkgs until we decide how to handle that.

[Mic92]

@winterqt what do you want to know about mergify? There is no much magic needed to use it. I can prepare a simple configuration. The big advantage of mergify over github merge queues is that, it allows to specify rules in a configuration file, so we don't need admin rights every time we add a new check. The other advantage is that the merge action can be triggered with labels, which allows for automerging backports for example.

[winterqt]

I'm saying that that's sort of a large enough change that we'd need to communicate to all committers -- I'd rather not have some people using it and some not.

[Mic92]

Well. Before we make it mandatory, we should evaluate it in a smaller group. If the alternative is not using merge queues, there is no downside if some testers are using it. We also need this feature for merge-bot.

[Mic92]

New issue: #39

[winterqt]

I'm going to block figuring this out on an SC discussion, just since that's the most relevant regulatory body we have at the moment.

[infinisil]

@winterqt I guess you mean #39, not this issue.

[zimbatm]

Can the SC allocate some nixpkgs owners?

As an org owner, I could approve both the GitHub App and Mergify to unblock the team. But since there is no nixpkgs team, who decides which path to take is unclear.

On a personal level, outsourcing the merge queue seems better. It's one less thing to maintain and also ties us less to GitHub.

[winterqt]

Done. We'll follow up on the Mergify stuff soon.

[infinisil]

With this done, NixOS/nixpkgs#360260 is now ready :)