ci: triage the GitHub milestone after a release by mwbrooks · Pull Request #660 · slackapi/slack-cli

mwbrooks · 2026-08-28T23:43:00Z

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.

Confirm the dry run above reports the milestone and open items you expect:
```
$ DRY_RUN=true ./scripts/triage-milestone.sh v4.8.0
```
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.
Run it a second time and confirm it reports No "Next Release" milestone was found, so nothing is triaged without creating a duplicate.

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

I've read and understood the Contributing Guidelines and have done my best effort to follow them.
I've read and agree to the Code of Conduct.

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.

codecov · 2026-08-28T23:49:21Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.21%. Comparing base (c6b3a21) to head (0780578).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #660      +/-   ##
==========================================
+ Coverage   78.19%   78.21%   +0.02%     
==========================================
  Files         239      239              
  Lines       18135    18135              
==========================================
+ Hits        14180    14184       +4     
+ Misses       3955     3951       -4

☔ 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.

zimeg

@mwbrooks LGTM! And nice saves for tedious efforts otherwise. I like to have these processes as a script also.

Good catches with "dev-build" and featuresets released too!

zimeg · 2026-08-31T20:22:14Z

+
+REPO=${REPO:-slackapi/slack-cli}
+DRY_RUN=${DRY_RUN:-false}
+UPCOMING_TITLE="Next Release"


🌟 praise: Thanks for keeping standard casing here!

zimeg · 2026-08-31T20:24:31Z

 Credentials and secrets for the app can be stored as the following variables:

- `GH_APP_ID_RELEASER`
+- `GH_APP_CLIENT_ID_RELEASER`


💌 praise: Thanks for following up after #640!

zimeg · 2026-08-31T20:26:05Z

 ### `scripts/`

-Installation and setup scripts for various operating systems are available here.
+Installation and setup scripts for various operating systems are available here,
+along with scripts that support the release process.


💡 thought: I'm curious to separate outward facing scripts from maintenance details but think we can discuss this more later:

.github/scripts/triage-milestone.sh

$ slack maintainer triage-milestone

@zimeg I agree. This has crossed my mind as well. Let's merge this PR and open a discussion around this one.

mwbrooks · 2026-08-28T23:50:41Z

+     ```sh
+     $ DRY_RUN=true ./scripts/triage-milestone.sh v4.8.0
+     $ ./scripts/triage-milestone.sh v4.8.0
+     ```


note: It's nice that we can run this script manually as well. 👌🏻

mwbrooks · 2026-08-31T23:27:01Z

 ### `scripts/`

-Installation and setup scripts for various operating systems are available here.
+Installation and setup scripts for various operating systems are available here,
+along with scripts that support the release process.


@zimeg I agree. This has crossed my mind as well. Let's merge this PR and open a discussion around this one.

mwbrooks · 2026-08-31T23:34:43Z

Thanks for the reviews @zimeg 🙇🏻 I'll open a discussion around how we want to separate maintainer and automation scripts! 🚢

mwbrooks added this to the Next Release milestone Aug 28, 2026

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

ci: name the milestone job for the checks list

dd69644

mwbrooks self-assigned this Aug 28, 2026

mwbrooks added 2 commits August 28, 2026 17:00

ci: drop the milestone test make target

5c91389

Merge branch 'main' into mwbrooks-triage-milestone

485b45f

mwbrooks marked this pull request as ready for review August 29, 2026 00:01

mwbrooks requested a review from a team as a code owner August 29, 2026 00:01

zimeg approved these changes Aug 31, 2026

View reviewed changes

Merge branch 'main' into mwbrooks-triage-milestone

0780578

mwbrooks commented Aug 31, 2026

View reviewed changes

mwbrooks merged commit f36b480 into main Aug 31, 2026
13 checks passed

mwbrooks deleted the mwbrooks-triage-milestone branch August 31, 2026 23:34

Navigation Menu

Uh oh!

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

ci: triage the GitHub milestone after a release#660
mwbrooks merged 5 commits into
mainfrom
mwbrooks-triage-milestone

mwbrooks commented Aug 28, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Aug 28, 2026 •

edited

Loading

Uh oh!

zimeg left a comment

Uh oh!

zimeg Aug 31, 2026

Uh oh!

zimeg Aug 31, 2026

Uh oh!

zimeg Aug 31, 2026

Uh oh!

mwbrooks Aug 31, 2026

Uh oh!

mwbrooks Aug 28, 2026

Uh oh!

mwbrooks Aug 31, 2026

Uh oh!

mwbrooks commented Aug 31, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mwbrooks commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog

Summary

Preview

Testing

Notes

Requirements

Uh oh!

codecov Bot commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

zimeg left a comment

Choose a reason for hiding this comment

Uh oh!

zimeg Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

zimeg Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

zimeg Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

mwbrooks Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

mwbrooks Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

mwbrooks Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

mwbrooks commented Aug 31, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mwbrooks commented Aug 28, 2026 •

edited

Loading

codecov Bot commented Aug 28, 2026 •

edited

Loading