Skip to content

ci: triage the GitHub milestone after a release - #660

Open
mwbrooks wants to merge 4 commits into
mainfrom
mwbrooks-triage-milestone
Open

ci: triage the GitHub milestone after a release#660
mwbrooks wants to merge 4 commits into
mainfrom
mwbrooks-triage-milestone

Conversation

@mwbrooks

@mwbrooks mwbrooks commented Aug 28, 2026

Copy link
Copy Markdown
Member

Changelog

No user-facing changes. This is release automation only.

Summary

This pull request automates the GitHub milestone triage that currently happens by hand after every release.

  • Publishing a production release now renames the Next Release milestone to the release tag, closes it, and creates a fresh Next Release
  • Issues and pull requests still open on the released milestone move forward to the new Next Release
  • Items with no milestone are left alone
  • Merged and closed items stay on the release tag milestone, so its history is preserved

The logic lives in scripts/triage-milestone.sh rather than inline in the workflow so a maintainer can preview it, rehearse it, or recover by hand when CI fails. Completed steps are skipped, so an interrupted run is safe to repeat.

Preview

A dry run against this repository, which makes no changes:

$ DRY_RUN=true ./scripts/triage-milestone.sh v4.8.0
Triaging the "Next Release" milestone of slackapi/slack-cli for v4.8.0
-> Renaming milestone #33 to v4.8.0
   Skipping the 'title=v4.8.0' change of milestone #33
-> Creating the next "Next Release" milestone
-> Moving open issues and pull requests to "Next Release"
   Skipping the milestone change of #659
   Skipping the milestone change of #644
   Skipping the milestone change of #630
   Skipping the milestone change of #629
   Skipping the milestone change of #624
-> Closing milestone v4.8.0
   Skipping the 'state=closed' change of milestone #33
Triaged the milestone of v4.8.0

Testing

Note: Only the DRY RUN has been verified. Optionally, we can test on a scratch repository. Otherwise, we can merge this PR and test on the next release.

  1. Confirm the dry run above reports the milestone and open items you expect:
    $ DRY_RUN=true ./scripts/triage-milestone.sh v4.8.0
  2. Rehearse the actual writes against a scratch repository, since they are not exercised anywhere else. Create a Next Release milestone there with one open and one closed issue, then:
    $ REPO=<you>/scratch ./scripts/triage-milestone.sh v0.1.0
    Confirm v0.1.0 is closed and holds the closed issue, and that a new open Next Release holds the open issue.
  3. Run it a second time and confirm it reports No "Next Release" milestone was found, so nothing is triaged without creating a duplicate.
  4. Confirm the releaser app grants the new permission, otherwise every milestone write returns a 403:
    $ gh api /orgs/slackapi/installations \
        --jq '.installations[] | select(.app_slug=="slack-cli-releaser") | .permissions'

Notes

  • The write paths have not run yet. Only the dry run is verified, so the rename, create, move, and close calls execute for the first time on the next real release. The script is resumable and each step is reversible from the milestones page, but reviewers may prefer the scratch repository rehearsal in step 2 before merging.
  • A new app permission was required. Milestone create, rename, and close go through the Issues API, which the releaser app did not have. Issues: Read and write was added and granted to installation.
  • Next Release is now hard-coded in three places: release.yml, dependencies.yml, and this script. Renaming it breaks all three together, which the maintainer's guide now warns about.
  • Development and feature builds are skipped because CircleCI publishes them as prereleases, with a vX.Y.Z regex as a second guard.

Requirements

The "Next Release" milestone is renamed to the published release tag and
closed, while a new "Next Release" milestone gathers the issues and pull
requests that remain open. Items without a milestone are left alone.

This was a manual step of the release runbook. The logic lives in
scripts/triage-milestone.sh so a maintainer can rehearse it with DRY_RUN
or run it by hand, and completed steps are skipped so an interrupted run
is safe to repeat.

The releaser app needed a new Issues permission to write milestones.
@mwbrooks mwbrooks added this to the Next Release milestone Aug 28, 2026
@mwbrooks mwbrooks added code health M-T: Test improvements and anything that improves code health semver:patch Use on pull requests to describe the release version increment labels Aug 28, 2026
@codecov

codecov Bot commented Aug 28, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.54%. Comparing base (b589377) to head (485b45f).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #660      +/-   ##
==========================================
- Coverage   72.59%   72.54%   -0.05%     
==========================================
  Files         239      239              
  Lines       20228    20228              
==========================================
- Hits        14684    14675       -9     
- Misses       4274     4277       +3     
- Partials     1270     1276       +6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@mwbrooks mwbrooks self-assigned this Aug 28, 2026
@mwbrooks
mwbrooks marked this pull request as ready for review August 29, 2026 00:01
@mwbrooks
mwbrooks requested a review from a team as a code owner August 29, 2026 00:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

code health M-T: Test improvements and anything that improves code health semver:patch Use on pull requests to describe the release version increment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant