The additional `workflows` permissions are required to backport
Dependabot updates. The permissions had been added to the app a while
ago, but we forgot to actually use them.
(cherry picked from commit bb1529ef6a)
None of our jobs is expected to run for 6 hours, the GitHub limit. These
limits are generous and take into accounts that some jobs need to wait
for others.
If jobs exceed these times, most likely something else is wrong and
needs investigation.
(cherry picked from commit 436d54174d)
When a PR is merged and labeled afterwards - with a non-backport label -
the following will happen:
- The first backport job is triggered on the merge.
- The second backport job is triggered on the label event.
- The second job will cancel the first one due to the concurrency group.
- The second job will cancel itself because the label event didn't
contain a backport label.
Both jobs end up cancelled and no backport happens.
We made the backport action idempotent upstream a while ago, so we don't
need to cancel those actions. Instead, we'll run all of them -
subsequent actions running through will just stay silent anyway.
(cherry picked from commit 58a3001a3a)
This will give us a better idea about:
- Which jobs use the most API calls and can possibly be made more
efficient.
- Which rate limits apply exactly to which tokens.
(cherry picked from commit 356bf98a32)
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)
When backporting a change to 24.11 and 25.05 at the same time by adding
the two labels immediately *after* merging the PR, three backport jobs
will run concurrently: One for the merge and one for each label added.
Each of those jobs will try to create both PRs, which will lead to two
of the jobs failing for sure.
With a concurrency group and cancelling in-progress jobs, only one of
those jobs will remain. This reduces notification noise.
(cherry picked from commit 6276e09530)
github-script provides a better way to access the workflow's context
than bash variables + interpolation. Especially when considering future
changes, where you'll always be tempted to just use interpolation
directly in bash code.
(cherry picked from commit e344fdcc26)
Granting the "issues: write" permission allows creating the "port to
stable" label, if it doesn't exist, yet. This avoids failing the
workflow when testing in a fork without that label.
(cherry picked from commit e8906ae26c)
After creating the backport successfully, we previously created the
"has: port to stable" label with the Nixpkgs CI App's token. This would
trigger another labeled event for the backport workflow. This only
appears as "skipped", so doesn't use any resources, but it clutters the
GitHub Actions output with useless skipped workflows.
Using `github.token` does not trigger any other workflows so avoids that
problem.
(cherry picked from commit 2566f9dcb4)
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
Somehow, the was_successful output didn't work correctly. It's hard to
imagine that the created_pull_numbers output fails the same way,
because... when the backport action fails there **are no pull request
numbers**.
This allows filtering for PRs with a backport label, but without the
"has: port to stable" label to find those which need to be manually
acted on.
Resolves#325359
The backport job was previously triggered on any label activity, i.e.
when the backport label was already set and a new label added, the
backport would have been triggered again.
That's because github.event_name is actually "pull_request_target" in
this case, not "closed" or "labeled" (the event's types). Thus, this
part of the condition was always true.
This also means that the second part, the startsWith, was never
evaluated. It had its arguments flipped and would have always been
false.
This was introduced in #126825, but has never really worked as intended.
Resolves#199556
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.
