Repository navigation
Take the release version as a workflow input and run the checks on the bump PR - #872
Merged
Merged
Conversation
|
This was referenced Oct 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Checklist
Description
Each release still needs two manual steps around the workflow. Before it runs, the pom and README version bump gets pushed straight to master, so the generated release notes leave it out. After it runs, the "Version Release" PR is opened with
GITHUB_TOKEN, so the required checks never run on it and it needsgh pr merge --admin.The release workflow now takes the version to release as an input (e.g.
14.3.0).github-build.shsets it in the pom and in the two README snippets (Gradle and Maven) instead of stripping-SNAPSHOT, and stops before deploying if it isn'tX.Y.Z. The pom on master still has to end with-SNAPSHOT. The README change gets to master through the Version Release PR like the pom does. The previous release tag is looked up first now, so ifghfails the run stops before anything is published.After opening the PR, the workflow runs
gh workflow run pull-request.yml --ref version-release. GitHub doesn't start workflows for events made withGITHUB_TOKEN, exceptworkflow_dispatchandrepository_dispatch, so this runs the checks on the PR's head commit. The PR still needs an approval, which any of us can give since the bot opened it. create-pull-request recommends a GitHub App token for this, but that needs an org app and two secrets. This needs none.I ran
github-build.shin an Ubuntu container withmvnandghstubbed and pushes going to a local repo. With14.3.0the pom and both README lines became14.3.0,v14.3.0was pushed, the draft release started fromv14.2.0and the next version was14.3.1-SNAPSHOT. With14.3it stopped before the deploy. actionlint passes.Not verified yet: that the dispatched runs count as the required
build (N)checks on the PR.workflow_dispatchonly works once the workflow is on master, so after this merges I'll dispatch it on #848's branch to check, before releasing 14.3.0. The "Releasing a version" wiki page gets updated after the merge too.🤖 Generated with Claude Code