fix: the labeler test no longer assumes area:ci exists in the repository's labels.yml - #67
Conversation
…ory's labels.yml The last case ticked area:ci and asserted it was applied, which holds in the template and fails in every adopter that renamed the starter areas — which the template tells them to do. Reproduced against a downstream repository with nine contract areas: make check red on day one. The case now takes the first declared area, whatever its name, and passes trivially when none is declared. Closes #66 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c05d14b31
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| assert.deepEqual(r.toAdd, ['area:ci']); | ||
| if (areas.length === 0) return; // an adopter may have dropped the family entirely | ||
| const first = areas[0]; | ||
| const r = changes(`### Area\n\n- [x] ${first} — declared\n- [x] area:not-declared-anywhere — n`, [], areas); |
There was a problem hiding this comment.
When an adopter legitimately declares area:not-declared-anywhere after another area, this supposedly portable test selects two allowed labels, so toAdd contains both and make check fails. Because .github/labels.yml permits adopters to choose their own area names, derive a sentinel that is confirmed absent from areas rather than hard-coding another label name.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 8e49b61: the sentinel starts as area:undeclared and grows -x until it is absent from the declared set.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
🤖 I have created a release *beep* *boop* --- ## [0.5.1](v0.5.0...v0.5.1) (2026-09-16) ### Bug Fixes * the labeler test no longer assumes area:ci exists in the repository's labels.yml ([#67](#67)) ([eafbfd6](eafbfd6)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
1 participant
Summary
scripts/issue-labeler.test.js's last case hardcodedarea:ci. It passes here and in adopters that kept the starter areas, and fails in every adopter that renamed them — found by simulating the v0.5.0 labeler set against a downstream repository with nine contract areas (not ok 14,make checkred). The case now uses the first declared area, whatever it is, and passes trivially with none.Related issue
Closes #66
Validation
make verifygreenlabels.ymldeclaring onlyarea:a-architecture … area:pm(real downstream copy); 14/14 with alabels.ymldeclaring noarea:*at allRisk / rollback
Checklist
*.local.mdfiles committed