Instead of relying on workflow_run events, we now trigger the labeling
workflow by schedule. This avoids all permission/secrets problems of
running in the pull_request_review context - and also gets rid of the
"waiting for approval to run workflows" button for new contributors that
sometimes comes up right now.
Also, it's more efficient. Previously, the labeling workflow would run
on *any* pull_request_review event, which happens for all comments, too.
So quite a few runs.
This will cause a delay of up to 1 hour with the current settings until
approval labels are set. Depending on how long the job normally runs we
can adjust the frequency. The workflow is written in a way that will
work no matter what the frequency ends up being, even when it's
interrupted by transient GHA failures: It will always look at all PRs
which were updated since the last time the workflow ran successfully.
We also add the ability to run it manually via UI. This is useful:
- When fixing bugs in the labeler workflow to run it all the way back to
where the bug was introduced.
- When introducing new labels, to get a head start for a reasonable
amount of PRs immediately.
Of course, the workflow is also still run directly after Eval itself.
This is also the only case that the actions/labeler steps will run,
since they depend on the `pull_request` context.
(cherry picked from commit 6f12f662ae)
This currently fails with:
```
Method Set.prototype.has called on incompatible receiver undefined
```
Seems like my syntax test previously only hit the case without
maintainers, in which case it doesn't throw :/.
(cherry picked from commit 4b9fb45060)
This didn't work as intended. When a workflow is run with
`workflow_call`, it will have `github.workflow` set to the *parent*
workflow. So the `caller` input that we passed, resulted in this
concurrency key:
```
Eval-Eval-...
```
But that's bad, because the labels and reviewers workflows will cancel
each other!
What we actually want is this:
- Label and Reviewers workflow should have different groups.
- Reviewers called via Eval and called directly via undraft should have
*different* groups.
We can't use the default condition we use everywhere else, because
`github.workflow` is the same for Label and Reviewers. Thus, we hardcode
the workflow's name as well. This essentially means we have this as a
key:
```
<name-of-running-workflow>-<name-of-triggering-workflow>-<name-of-event>-<name-of-head-branch>
```
This should do what we want.
Since workflows can be made reusable workflows later on, we add those
hardcoded names to *all* concurrency groups. This avoids copy&paste
errors later on.
(cherry picked from commit 6793e238fa)
This can happen when two PRs run at the same time, which come from
different forks, but have the same head branch name.
github.head_ref is suggested by GitHub's docs, but.. that's not really
useful for cases with forks.
(cherry picked from commit 7ba7720b28)
The category 12 labels for number of approvals and approved by package
maintainer are now automatically managed by the labels workflow. The
logic is slightly different from the "by: package-maintainer" label. For
approval, it's enough if *any one* maintainer approves the PR to have
the label added, even if the PR touches multiple packages.
The workflow only counts approved reviews, no matter whether there had
been a push in the meantime or not. To achieve the currently used logic
of "expiring approvals after push", we will have to set up a branch
protection rule, which actually dismissed those reviews automatically.
(cherry picked from commit 5f09e16f00)
This moves the actual labeling from the eval workflow to the labels
workflow. At this stage, this only has a disadvantage: Adding the
topic-labels to the pull request will now only happen after eval has
finished, instead of instantly.
We will only benefit from this later, when we manage approval related
events. With this change, we will have the comparison results and thus
the package maintainer info available.
(cherry picked from commit 2d0bcd7165)
We can avoid running old jobs to completion, when pushing changes to a
pull request. This is done via concurrency groups. We set them on the
workflow level, with the following keys in the group name:
- `github.workflow` to only cancel / block the same workflow.
- `github.event_name` to avoid blocking between pull_request and
pull_request_target.
- `github.head_ref` which is unique for a PR, but the same when changing
it. This will cause PRs to cancel in progress jobs. Unset on pushes to
master & co.
- `github.run_id` as fallback for push events. In this case, the run_id
is unique for every push, thus *no* cancelling happens on the dev
branches.
(cherry picked from commit 6d4b1f8e30)
A while ago, I added those "owner == NixOS" conditions, because I
couldn't figure out why my fork kept failing those jobs, even though I
had set up the apps correctly.
Turns out, that when a label doesn't exist, those actions try to
implicitly create it. But to do that, they actually need write
permissions on the *issues* endpoint, the pull-requests endpoint is not
enough. Even though the docs state otherwise.
Thus, adding those permissions. This will also lead to new labels being
created when they are added via code (for example in
.github/labels.yml), even when they had not been created, yet. Labels
created this way will initially be grayish color and without description
- but we can always add those later, there is no point in failing
pipelines for everyone in that case.
(cherry picked from commit d2ff68b564)
We intend to use the edited event to react to base branch changes - but
before this change, we also ran those jobs on simple edits like title or
description.
While this works for some of the quicker jobs, it will not be
sustainable for all evaluation-related jobs. But evaluation needs to be
re-triggered on a base branch change as well, thus this change.
(cherry picked from commit 9b01e09a35)
ARM runners are supposed to be more energy efficient than x86. Also,
from limited testing, they appear to be faster for the eval jobs as
well. Average run time for the "Outpaths (x86_64-linux)" job was 4m 27s,
so far. In the first run, this job came in at 3m 9s. This effect did not
show for other jobs, yet.
The following two exceptions are made right now:
- nixpkgs-lib-tests currently fails on the ARM runner building Nix 2.3
- nixpkgs-vet is currently pinned to a x86_64-linux only binary release
Introduced in #402332, but broken on all ends:
- pull_request needs to be event.pull_request
- pull_request.head is an object, not a string
- github.ref_protected is about the target branch, because this runs as
a pull_request_target event
Thus, we need to list the branches manually.
Same top-level ordering of keys / empty lines and same indentation for
yaml lists. One blank line between each step.
Makes it easier to read and compare the workflows.
For reproducibility.
Command:
```shell
for file in .github/workflows/*.y*ml; do
npx pin-github-action --comment=' {ref}' "$file"
done
```
Then had to manually replace all the versions with accurate specifiers
(for example, "v4" → "v4.1.1" in case of `actions/checkout`).
