Applying the `breaking` label to an open pull request does not re-run the semver gate
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
Research direction
Read ci.yml around the pull request trigger and the semver step near line 312, then compare with docs/RELEASING.md:36. Check how the workflow receives label changes and evaluates the breaking label. Done when applying or removing the label re-evaluates the gate, or the docs state exactly when the label must be applied.
Written by the indexing model from the issue text.
Description
What happens. docs/RELEASING.md:36 says a breaking pull request "carries the breaking label (a maintainer applies it; the gate then runs with --release-type major)". But adding the label to an open pull request starts no CI run:
ci.ymldeclareson: pull_request:with notypes:. That fires only onopened,synchronizeandreopened, never onlabeledorunlabeled.- The semver step reads the label from the event payload (
BREAKING_LABEL: ${{ contains(github.event.pull_request.labels.*.name, 'breaking') }},ci.yml:312), so a re-run of an older run sees the labels as they were then.
The only breaking pull request so far, #346, got the label at creation: labelled 20:23:49, created 20:23:48. Its run logged BREAKING_LABEL: true, so the documented flow has only worked with gh pr create --label. The reverse holds too: removing the label leaves the last green major-type run standing.
Fix. Either add types: [opened, synchronize, reopened, labeled, unlabeled] and read the labels at run time (gh api repos/$REPO/issues/$PR/labels), or correct RELEASING to say the label must be applied when the pull request is opened, or followed by a push.
Done when applying or removing the label re-evaluates the gate, or the docs say exactly what does.
- Dominant language
- Rust
- Stars
- 28
- Forks
- 24
- Avg merge
- 11h 23m
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from vyncint/termlens
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
Release notes show a broken link: `extract-changelog.sh` copies a reference but not its definitionOpenbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
All issues in vyncint/termlens
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
compiler P4 perf
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
HerringtonDarkholme/hd-lang#1044 ·
Maintainers usually reply within 1 day
-
good first issue help wanted r-docs
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
servo/rust-smallvec#824 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
akitaonrails/ai-usagebar#552 ·
Maintainers usually reply within 1 day