Running the nixpkgs-merge-bot in GitHub Actions instead of a separate
workflow has multiple advantages:
- A much better development workflow, with improved testability.
- The ability to label PRs with a "merge-bot eligible" label from the
same codebase.
- Using more data for merge strategy decisions, for example the number
of rebuilds.
This commits re-implements most of the features from the current
nxipkgs-merge-bot directly in the bot workflow. Instead of reacting to
webhook events, this now runs on the regular 10 minute schedule. Some
merges might be delayed a few minutes, but that should not be a problem
in practice.
To give the user early feedback, there are additional workflows running
when a comment or review is posted. These react with "eyes" to make the
user aware that the comment has been recognized.
The only feature not taken over was the size check for files in the PR.
This kind of check is not really relevant for maintainer merges only -
if we want to prevent bigger files from making it into the tree, then we
need a generic CI check, which is out of scope for the merge-bot.
Other than that, everything should be implemented - any omissions are by
accident.
This is just a separate commit for a better diff. This workflow will be
extended with the `submitted` type in the next commit, so needs a
different naming.
While at it, also remove the useless concurrency group: This workflow is
never run in a PR context, so will never be cancelled.
This workflow / script is already doing more than must labeling: it's
already auto-closing package request issues.
Since we're going to migrate the nixpkgs-merge-bot into this workflow,
we'll rename things to a more generic name.
To be able to disable the pr.yml workflow on GitHub, we need to rename
it to a different name. Let's use the long name for consistency with
merge-group.yml. This only affects the GitHub-internal name, not the
visible name in the PR checklist, which is still "PR". This visible name
is also used by nixpkgs-review, so that won't break.
In f7d6d11e8e I wrongly assumed that
running from the untrusted checkout should be fine for the codeowners
validator, because we removed all the logic for privileged tokens.
However, this job also contains access to the cachix secret, which could
be used to push malicious code to cachix, which would then be pulled by
a more privileged workflow like reviewers.yml later.
We recently retired a lot of old aliases, but emacsPackages is still
exposed on search.nixos.org, so should not have been removed. I argued
previously, that this should not have been an alias in the first place:
If it's exposed on search.nixos.org, then it is expected to be used,
too.
We will also need that once we teach Eval to evaluate more packages than
hydra builds.
Wolfgang Walther