feat: add release-please for automated releases#306
Conversation
Replace manual publish workflow with release-please automation. On push to main, release-please creates a release PR with version bump and changelog. Merging the PR triggers Maven Central publish.
|
🐕 Review complete — View session on Shuni Portal 🐾 |
There was a problem hiding this comment.
🐕 Shuni's Review
Replaces manual publish.yaml (triggered on GitHub release) with release-please.yaml that automates version bumps, changelogs, and Maven Central publishing via a two-phase workflow.
No issues found — good bones! Manifest version matches pom.xml, bootstrap SHA points to the correct commit, publish job correctly checks out the release tag, and Maven credentials are carried over identically. Woof!
There was a problem hiding this comment.
Pull request overview
Introduces release-please-based automation to replace the manual release-triggered publish workflow, so releases are generated via a Release PR and publishing to Maven Central happens only when a GitHub Release is created.
Changes:
- Added
release-pleaseconfiguration + manifest for versioning and changelog generation. - Added a new
Release PleaseGitHub Actions workflow that creates Release PRs and publishes on release creation. - Removed the legacy
publish.yamlworkflow that published on GitHub Release creation.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
release-please-config.json |
Configures release-please (simple strategy) and adds XML-based version bumping for pom.xml. |
.release-please-manifest.json |
Initializes the manifest version for the root package. |
.github/workflows/release-please.yaml |
Adds combined release-please + Maven Central publish workflow. |
.github/workflows/publish.yaml |
Removes the prior release-triggered publish workflow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The simple type with XPath doesn't handle Maven's XML namespace. The maven release type natively handles pom.xml version updates, matching the pattern of other SDKs (python uses python, node uses node). Also adds include-v-in-tag: false to match existing tag format.
No new secrets needed — uses the same GITHUB_TOKEN that's already available. The publish job runs in the same workflow via release_created output, so a GitHub App token is unnecessary.
|
@shuni please fix Omer's comment #306 (comment) |
|
🐕 Done! Updated PR: #306 📋 Actions TakenView AI responsePerfect! I've successfully fixed Omer's comment. Here's what I did: Changes MadeUpdated
This follows the exact same pattern used in CommitCreated commit The workflow is now ready and matches the established pattern across Descope repos! 🐕 |
The release-please action needs to use a GitHub App token instead of the default GITHUB_TOKEN to ensure the publish workflow is triggered when a release PR is merged. This follows the same pattern used in descope-dotnet and other repos. Changes: - Add step to generate token from RELEASE_APP_ID and RELEASE_APP_PEM - Pass token to release-please action - Reduce workflow permissions to contents:read (app token has necessary permissions) Co-authored-by: Shuni <251468265+shuni-bot[bot]@users.noreply.github.com>
Summary
publish.yamlworkflow withrelease-please.yamlrelease-please-config.jsonand.release-please-manifest.jsonsimplerelease type with XML XPath to bumppom.xmlversion (same pattern as descope-dotnet)How it works
main→ release-please creates/updates a "Release PR" with version bump + CHANGELOGmvn -B deploy -P cicommand and credentials as beforePrerequisites
RELEASE_APP_IDandRELEASE_APP_PEMsecrets must be configured (same GitHub App used by python-sdk, node-sdk, descope-dotnet)Test plan
pom.xmlversion and generates CHANGELOG.md