These jobs were recently introduced into the merge queue - but I forgot
to make them actually required. They sometimes fail - but the PR is
still merged. Dumb.
This partially reverts commit 1289456d3b.
The external action we use to merge branches runs in a docker container,
which is not possible with the ubuntu-slim runner.
This is in public preview now. These runners run in a docker container
with only a single vCPU instead of 4 like the other jobs. For most of
our jobs, this should be plenty, except for eval and linting.
If cachix fails to install, we don't actually need to error out - we can
still continue at the cost of building stuff more than required. That's
better than erroring out, just because cachix has another hiccup,
especially for the Merge Queue.
Since it was previously possible, in theory, to extract the
CACHIX_AUTH_TOKEN via Nix eval on untrusted inputs, this rotates the
token and clears the cache - and while on it moves to a new cache, that
is owned by a newly created nixpkgs-ci org instead of an individual.
Evaluating untrusted code in the presence of secrets is unsafe in
general, thus we only provide the cachix auth token when these jobs run
in the merge queue. This is enough for all practical purposes, PRs will
be able to pull stuff from cachix that was built in the Merge Queue
previously.
This migrates the bash code to request reviewers to github-script. This
will allow multiple nice improvements later on, but at this stage it's
mostly a reduction in code and complexity.
This makes reactions to merge comments and all the labeling a bit
quicker. Lower the number of backlog items to process per run
accordingly, so that we don't really need more API requests for it.
The last user to touch the schedule will be notified about errors in the
scheduled run. I used to be that, but somehow when renaming the workflow
this didn't happen anymore, so I didn't noticed the workflow failing for
quite some time.
All other conditions equal, there is no reason to prevent maintainers
from backporting changes to their packages. Maintainers are probably in
the *best* position to tell whether a certain change is backportable or
not - because they know the package well.
We still get plenty of errors in the prepare step for the diff requests
to take way too long - let's increase the number of retries massively
now. These are repeated with exponential backoff, so hopefully they will
succeed with some cooldown, when GitHub had time to compute the right
diff in the background.
The nixpkgs-ci token used in CI doesn't have permissions to read the
member list of the nixpkgs-committers team, yet. Let's request this
permission and see whether that fixes the errors we get so far.
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.
