Release hygiene: label name, canary auto-close, coverage doc, allowlist honesty - #671
Conversation
…st honesty Four small fixes ahead of v0.10.0: - .github/release.yml excluded the label `github-actions`, which does not exist in this repo; the real label is `github_actions` (28 merged PRs carry it, none carry the hyphen form). Latent today because the author exclusion catches dependabot, but a human-authored CI PR would have leaked into "Other Changes". - installer-smoke.yml gains a `recover` job: on a fully green run it closes any open "Installer canary failure" issue, using the same exact-title lookup as the notify job. Without it a single blip leaves a permanently open issue — #644 sat open ten days across ten green runs. - API-COVERAGE.md's header had drifted three SDK bumps behind the pin: it claimed v0.12.0 (actual: v0.15.0), still carried the uploads-versions gap that closed with v0.14.0's typed ListVersions (basecamp/basecamp-sdk#683 — the `uploads` row already documented the shipped command), and said the field-keyed 422 fix was "past this pin" when #541 landed inside it at v0.13.0. Summary is now 184/184 with the Blocked status retained at zero. The endpoint-count reconciliation the file defers stays deferred. - check-cli-surface-diff.sh's header said to clear .surface-breaking after each release; five months and several releases in, nobody ever has, RELEASING.md never mentions it, and nothing depends on it. The comment now describes the allowlist as what it is: cumulative.
Sensitive Change Detection (shadow mode)This PR modifies control-plane files:
|
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. |
There was a problem hiding this comment.
Pull request overview
Improves release hygiene, canary recovery, and documentation accuracy ahead of v0.10.0.
Changes:
- Corrects release-note label filtering.
- Automatically closes recovered installer-canary issues.
- Updates SDK coverage and surface-allowlist documentation.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
.github/release.yml |
Uses the repository’s actual Actions label. |
.github/workflows/installer-smoke.yml |
Closes open canary issues after successful runs. |
API-COVERAGE.md |
Updates SDK version and endpoint coverage. |
scripts/check-cli-surface-diff.sh |
Documents the cumulative allowlist behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
![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: 9f665fbd7b
ℹ️ 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".
…ist candor Codex pointed out the recover job's exact-title lookup breaks the moment a human retitles the issue — the repo already learned this (#607 filed alongside the retitled #602) and built notify-issue.sh, label-keyed and fail-closed, to stop it. The notify job here was carrying a third inline title-based copy of that logic, so both jobs move to the installer-canary label: notify goes through notify-issue.sh, recover closes every open labeled issue on a green run (one worth keeping open sheds the label). Lookup failure skips the close with a warning rather than reading as "nothing open". Copilot caught the fieldErrors correction leaving the same stale claim in three more places: the calendars row here and both comments in calendars.go still said the pinned SDK cannot carry the 422 field message. All three now say what's true — the local check stays for an immediate answer naming the alternatives; the server's field-keyed message has come back since v0.13.0. The allowlist comment also overclaimed: an entry does not excuse only "the removal it names" — it excuses every future removal of that surface line, including one after a reintroduction. Said so, and named the clear-at-release step that would scope it.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e59e54875
ℹ️ 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".
Both reviewers caught it: the workflow sets permissions: {} globally,
and the checkout added for notify-issue.sh gets no repository access
from issues: write alone — the job would die before filing the issue,
exactly on the runs it exists for. Same non-inheritance note as
release.yml documents for its headless-probe call.
Four small fixes ahead of the staged v0.10.0:
.github/release.yml— the excluded label doesn't existgithub-actions→github_actions(gh label listhas only the underscore form; 28 merged PRs carry it, 0 carry the hyphen). Latent today because the author exclusion catches dependabot, but a human-authored CI PR would leak into "Other Changes". Rode along with the note that #646 now carries thebreakinglabel so the generated notes state thetimeline --watchremoval.installer-smoke.yml— close the canary issue on recoveryNew
recoverjob (if: success(), sameneedsand exact-title lookup asnotify) closes an open "Installer canary failure" issue with a link to the green run. Without it every blip leaves a permanently open issue — #644 sat open ten days across ten consecutive green runs after a single unauthenticated-API rate-limit blip on the Windows leg.actionlintandzizmorclean.API-COVERAGE.md— header was three SDK bumps behind the pinuploadsversions gap closed when v0.14.0's typedListVersionslanded (Uploads: replace a file in place, and say which file each version is basecamp-sdk#683) andfiles versionsshipped un-held — theuploadssection row already documented the command,.surfacecarries it, but the header still said 183/184 with 1 blocked. Now 184/184,parseErrorBodyparagraph said the field-keyed 422 fix was "past this pin"; Surface field-keyed 422 validation payloads in all six transports basecamp-sdk#541 landed at v0.13.0, inside it.check-cli-surface-diff.sh— describe the allowlist honestlyThe header said "Clear that file after each release." Five months, ~5 releases: never cleared,
RELEASING.mddoesn't mention it,.surface-breakingis 1074 cumulative lines, and nothing depends on clearing it — an entry only excuses the removal it names. The comment now says the allowlist is cumulative. (Actually clearing it at v0.10.0 and adding aRELEASING.mdstep is a valid alternative — defaulted to making the comment match five months of practice; happy to flip it.)bin/cigreen.Summary by cubic
Fixes release hygiene ahead of v0.10.0: canary failure issues now auto-close once a run is green, and the release-notes label exclusion uses the label that actually exists in the repo.
installer-smoke.ymlgains arecoverjob that closes open "Installer canary failure" issues on a green run with a link to the run; both it and the notify job key on theinstaller-canarylabel through the sharednotify-issue.sh, so a retitled issue is still caught, and the notify job now checks out the script (gainingcontents: readsince the workflow setspermissions: {}).github-actionslabel; the repo usesgithub_actions, so human-authored CI PRs would have appeared under "Other Changes."API-COVERAGE.mdand thecalendarscomments now pin SDK v0.15.0: coverage is 184/184 since v0.14.0's typedListVersionsun-heldfiles versions, and theparseErrorBody422 fix landed at v0.13.0 — the client-side color check stays as a fast local answer but no longer claims the SDK can't carry the message..surface-breakingallowlist comment now states the list is cumulative and never cleared; entries excuse every future removal of the same surface line.Written for commit 4a54408. Summary will update on new commits.