ci(changelog): re-run the check when PR labels change - #6916
ci(changelog): re-run the check when PR labels change#6916FarhanAliRaza wants to merge 3 commits into
Conversation
Greptile SummaryThe changelog workflow now reruns when pull-request labels change and reads the current labels through the GitHub API, ensuring changelog waivers are reevaluated rather than relying on stale event payloads.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| .github/workflows/changelog.yml | The workflow consistently fetches current PR labels and applies those outputs across all label-dependent checks; no eligible follow-up defect was identified. |
Reviews (3): Last reviewed commit: "ci(changelog): restore the label trigger..." | Re-trigger Greptile
Merging this PR will not alter performance
Comparing 
Footnotes
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 1 file
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
Reviewbot comment seems legit. Can you also apply this change to the template CI workflow that's part of reflex-release |
The skip-changelog and changelog-version-edit gates read github.event.pull_request.labels, which is a snapshot taken when the run was queued. A label applied after the last push is invisible to the run, and "Re-run failed jobs" replays that same stale payload, so the check keeps failing until someone pushes again. Read the labels from the API at job time instead, so a re-run picks up the current label set. This removes the need for the labeled/unlabeled trigger types added earlier on this branch, which fired for every label on every PR and cancelled in-progress runs for no change in outcome. Same approach aiohttp uses for its CHANGES-fragment check.
Dropping labeled/unlabeled left the opposite bug: removing skip-changelog produced no run at all, so the green computed while the label was applied stayed as the check's verdict and the gate silently stayed open. The verdict is only valid for the label set it was computed under, so a label change has to start a run. Keep the API read too: it is what makes "Re-run failed jobs" pick up the current labels instead of replaying the queued payload.
2 participants
The `changelog` workflow gates on the `skip-changelog` / `changelog-version-edit` labels, but it only ran on the default `pull_request` types (`opened`, `synchronize`, `reopened`). Adding a label after the last push never starts a new run, and re-running the failed run replays the original event payload where the label does not exist yet, so the check keeps failing until someone pushes again (see run 32273787477 on #6866).
Add `labeled` and `unlabeled` to the trigger types so toggling a label re-evaluates the check with the current label set.