What happened:
pr-kind-label.yaml and issue-kind-label.yaml both wipe every kind/* and area/* label and then re-add from the body. Neither declares a concurrency: group, so two runs in quick successive edits can interleave partway through that sequence and leave labels matching neither edit.
Copilot spotted it reviewing #2157: #2157 (comment)
It was not fixed in #2157 because pr-kind-label.yaml already had the same bug and wanted to keep the PR for the feature separate to the bug.
What you expected to happen:
Labels match the final body after a burst of edits. Each run finishes its remove and re-add as a unit instead of getting interleaved by the next one.
How to reproduce it (as minimally and precisely as possible):
- Open an issue with
/kind bug in the body
- Edit the body twice fast, so the second run starts before the first finishes
- Watch the two runs overlap in the Actions tab
This is timing dependent, so it won't hit every time. Same deal on pr-kind-label.yaml via pull_request_target: edited.
Anything else we need to know?:
The fix suggested by Copilot is the not the way to fix it. cancel-in-progress: true makes this worse because the cancel can land in the gap between the remove and the re-add. You end up with no kind/* labels at all. And if the newer body dropped the directive, the run that did the cancelling won't re-add them either, so they
just remain removed.
We want the queued run to wait instead of killing the one in flight. re-run-action.yml already does this:
concurrency:
group: ${{ github.workflow }}-${{ github.event.issue.number }}
cancel-in-progress: false
issue-kind-label.yaml can copy that as-is. pr-kind-label.yaml wants github.event.pull_request.number. The github workflow prefix keeps the two in separate groups.
Most workflows here use cancel-in-progress: true but they are idempotent check runs where binning a superseded run costs nothing. Doesn't apply to something that mutates state in two steps.
Related to #956, where both workflows came from.
Environment:
CI only. .github/workflows/pr-kind-label.yaml and .github/workflows/issue-kind-label.yaml on main.
What happened:
pr-kind-label.yamlandissue-kind-label.yamlboth wipe everykind/*andarea/*label and then re-add from the body. Neither declares aconcurrency:group, so two runs in quick successive edits can interleave partway through that sequence and leave labels matching neither edit.Copilot spotted it reviewing #2157: #2157 (comment)
It was not fixed in #2157 because
pr-kind-label.yamlalready had the same bug and wanted to keep the PR for the feature separate to the bug.What you expected to happen:
Labels match the final body after a burst of edits. Each run finishes its remove and re-add as a unit instead of getting interleaved by the next one.
How to reproduce it (as minimally and precisely as possible):
/kind bugin the bodyThis is timing dependent, so it won't hit every time. Same deal on
pr-kind-label.yamlviapull_request_target: edited.Anything else we need to know?:
The fix suggested by Copilot is the not the way to fix it.
cancel-in-progress: truemakes this worse because the cancel can land in the gap between the remove and the re-add. You end up with nokind/*labels at all. And if the newer body dropped the directive, the run that did the cancelling won't re-add them either, so theyjust remain removed.
We want the queued run to wait instead of killing the one in flight.
re-run-action.ymlalready does this:issue-kind-label.yamlcan copy that as-is.pr-kind-label.yamlwantsgithub.event.pull_request.number. The github workflow prefix keeps the two in separate groups.Most workflows here use
cancel-in-progress: truebut they are idempotent check runs where binning a superseded run costs nothing. Doesn't apply to something that mutates state in two steps.Related to #956, where both workflows came from.
Environment:
CI only.
.github/workflows/pr-kind-label.yamland.github/workflows/issue-kind-label.yamlon main.