workflows/{labels,reviewers}: fix concurrency groups for nested workflows#416448
workflows/{labels,reviewers}: fix concurrency groups for nested workflows#416448philiptaron merged 2 commits intoNixOS:masterfrom
Conversation
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.
b4fcd2d to
ea2ad3a
Compare
.github/workflows/README.md
Outdated
There was a problem hiding this comment.
Different users could have the same head branch name in their forks and run CI for their PRs at the same time.
I assumed that head_ref would be refs/pull/1234/head. Is it actually the branch name? 👀
There was a problem hiding this comment.
Yes, apparently. See for example the summary page here, section annotations: https://github.com/NixOS/nixpkgs/actions/runs/15634880254?pr=413785
There you can see the actual concurrency key used.
…lows 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.
ea2ad3a to
6793e23
Compare
philiptaron
left a comment
There was a problem hiding this comment.
Thank you for becoming an expert at this, @wolfgangwalther.
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-24.11
git worktree add -d .worktree/backport-416448-to-release-24.11 origin/release-24.11
cd .worktree/backport-416448-to-release-24.11
git switch --create backport-416448-to-release-24.11
git cherry-pick -x 7ba7720b28cc03d44d5ad1f5931ad4a88e068470 6793e238faeffcb58f1f6e1241c7390649fb8197 |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-25.05
git worktree add -d .worktree/backport-416448-to-release-25.05 origin/release-25.05
cd .worktree/backport-416448-to-release-25.05
git switch --create backport-416448-to-release-25.05
git cherry-pick -x 7ba7720b28cc03d44d5ad1f5931ad4a88e068470 6793e238faeffcb58f1f6e1241c7390649fb8197 |
This didn't work as intended. When a workflow is run with
workflow_call, it will havegithub.workflowset to the parent workflow. So thecallerinput that we passed, resulted in this concurrency key:But that's bad, because the labels and reviewers workflows will cancel each other!
What we actually want is this:
We can't use the default condition we use everywhere else, because
github.workflowis the same for Label and Reviewers. Thus, we hardcode the workflow's name as well. This essentially means we have this as a key:This should do what we want.
Things done
Add a 👍 reaction to pull requests you find important.