Create the release + release notes automatically#1689
Create the release + release notes automatically#1689cicoyle wants to merge 3 commits intodapr:masterfrom
Conversation
Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
There was a problem hiding this comment.
Pull request overview
Automates post-release steps by creating a GitHub Release (with auto-generated release notes) as part of the existing “Create a release” workflow.
Changes:
- Adds a conditional step to create a GitHub Release for non-
-SNAPSHOTand non--rc-versions. - Uses
gh release create ... --generate-notesauthenticated viaDAPR_BOT_TOKEN.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if: ${{ !endsWith(inputs.rel_version, '-SNAPSHOT') && !contains(inputs.rel_version, '-rc-') }} | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.DAPR_BOT_TOKEN }} | ||
| run: gh release create "v${{ inputs.rel_version }}" --generate-notes No newline at end of file |
There was a problem hiding this comment.
gh release create will error if a release for this tag already exists, which makes the workflow non-retriable after the release has been created once (e.g., if earlier steps need to be re-run). Consider adding a guard (e.g., gh release view <tag> and skip) or switching to an update flow (gh release edit) when the release already exists.
| run: gh release create "v${{ inputs.rel_version }}" --generate-notes | |
| run: | | |
| if gh release view "v${{ inputs.rel_version }}" >/dev/null 2>&1; then | |
| echo "Release v${{ inputs.rel_version }} already exists, skipping creation." | |
| else | |
| gh release create "v${{ inputs.rel_version }}" --generate-notes | |
| fi |
| if: ${{ !endsWith(inputs.rel_version, '-SNAPSHOT') && !contains(inputs.rel_version, '-rc-') }} | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.DAPR_BOT_TOKEN }} | ||
| run: gh release create "v${{ inputs.rel_version }}" --generate-notes No newline at end of file |
There was a problem hiding this comment.
create-release.sh already normalizes the input by stripping an optional leading v and then creates/pushes the tag as v$REL_VERSION. This step always prefixes another v ("v${{ inputs.rel_version }}"), so if the dispatch input is provided as v1.9.1 (which the script currently accepts), the workflow will try to create a release for tag vv1.9.1 which won't exist and the step will fail. Consider normalizing the input in this step the same way (strip a leading v) or otherwise reusing the exact tag name used by the script.
| run: gh release create "v${{ inputs.rel_version }}" --generate-notes | |
| REL_VERSION: ${{ inputs.rel_version }} | |
| run: | | |
| # Normalize release version by stripping an optional leading 'v' | |
| REL_VERSION="${REL_VERSION#v}" | |
| TAG="v${REL_VERSION}" | |
| gh release create "${TAG}" --generate-notes |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1689 +/- ##
============================================
- Coverage 79.53% 79.51% -0.02%
- Complexity 2193 2194 +1
============================================
Files 237 237
Lines 6577 6577
Branches 730 730
============================================
- Hits 5231 5230 -1
- Misses 990 992 +2
+ Partials 356 355 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Before this PR, this was a manual step after releasing. I am adding it to be created automatically for us to reduce the manual steps taken while releasing. I added the backport label so if we need to cut a patch for 1.17 it should auto generate the release and release notes for us.