ci: Release automation with release-please - #1398
Open
wojtas000 wants to merge 10 commits into
Open
Conversation
internal/version.Version is edited by hand and nothing fails when the bump is missed, so it drifts from the release tag: main shipped v2.1.0 and v2.2.0 while still reporting 2.0.0. Approach A fixes this with a bespoke workflow that pushes the bump to main, which needs github-actions[bot] on the branch-protection bypass list. Release Please gets the same result without that grant. It keeps one open release PR that rewrites the annotated constant, regenerates CHANGELOG.md and updates the manifest; merging that PR tags the merge commit, so a tag can only land on a commit whose constant already matches, and the bump goes through ordinary review. adk-python already releases this way, so this also aligns the two repos. Correct the constant to 2.2.0 (the current release) to seed the manifest, and document the flow, the conventional-commit requirement and the /v3 major-bump caveat in CONTRIBUTING.md. This is approach C of the version-drift RFC; approach A is on approach-a-release-workflow-bump and approach B on approach-b-derive-version-from-buildinfo.
adk-python stores both files there (.github/release-please-config.json and .github/.release-please-manifest.json, with a second -v1 pair for the maintenance line) and keeps the repository root clear of them. Match that layout so the two repos are configured the same way and the root stays reserved for Go module files.
The v1 branch is a separate release line on the unsuffixed google.golang.org/adk module path, with its own tags and its own copy of the version constant, so it cannot share main's manifest: one manifest holds one current version per package. Add .github/release-please-config-v1.json and .github/.release-please-manifest-v1.json, seeded at 1.6.0, which is where the v1 constant and the latest v1 tag already agree. The workflow now triggers on both branches, selects the pair from the branch it runs on, and passes target-branch explicitly so a v1 run cannot open a release PR against main. Concurrency is keyed per line so the two do not block each other. This mirrors adk-python, which keeps a -v1 config and manifest pair alongside the main ones and selects between them in release-cut.yml.
Forks inherit the workflow, so every push to a fork's main would start a release run: without RELEASE_PLEASE_TOKEN it fails, and with one it would try to cut a real release from the fork. Guard the job on the repository name, as adk-python's release-cut.yml does.
The pin was taken from refs/tags/v4's object SHA, but v4 is an annotated tag, so that SHA identifies the tag object rather than the commit it wraps. zizmor's ref-version-mismatch check flags the pin as disagreeing with its "# v4" comment, because the tag actually resolves to 5c625bfb5d1f. Pin that commit instead, which is also what adk-python pins.
…or-facing Drop the extra "deps" section: adk-go has no deps-typed commits, because dependabot writes chore(deps), which maps to the hidden chore section. Removing it leaves exactly the ten sections adk-python uses, in the same order, so the two repos produce comparably shaped release notes. Move the release mechanics out of CONTRIBUTING.md. Only maintainers cut releases, and the details (token setup, the v1 pair, the /vN major caveat) belong in the release playbook next to the rest of the procedure. What a contributor needs is one rule, so state it where PR requirements already live: titles are conventional commits, they become the squashed commit subject, and an unrecognised type is silently dropped from the notes and the version calculation.
wojtas000
changed the title
adk-python stores the equivalent credential as RELEASE_PAT. Using the same name means whoever provisions or rotates it recognises it across both repositories, and the release playbook can describe one secret rather than two names for the same thing.
wojtas000
force-pushed
the
ci/release-please-version-automation
branch
from
August 25, 2026 08:36
45c76cc to
9f4ec4a
Compare
wojtas000
changed the title
wojtas000
marked this pull request as ready for review
August 25, 2026 08:55
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
1 participant
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.
Problem
internal/version.Versionis edited by hand before every release, and nothing failswhen that is missed - so it drifts.
mainshipped v2.1.0 and v2.2.0 while stillreporting
2.0.0. The value reaches users: it is sent to Gemini in thegoogle-adk/<version>header, attached to every OTel trace and log as theinstrumentation version, and reported as the MCP client version.
Solution
Adopt Release Please - tool adk-python already releases with - to maintain the constant instead.
On each push to a release line, Release Please keeps a single open release PR that
bumps the annotated constant, regenerates
CHANGELOG.md(optional) and updates the manifest.Merging that PR tags the merge commit and publishes the release, so a tag can only
land on a commit whose constant already matches.
mainandv1share one workflow but have separate config/manifest pairs, so the twolines advance independently.
This also corrects the constant to
2.2.0, the current release.Prerequisites (not in this PR)
RELEASE_PATsecret - a GitHub App token or PAT. A PR opened with thebuilt-in
GITHUB_TOKENdoes not trigger other workflows, so the release PR wouldget no CI.
v1(keeping its own1.6.0constant).Until then only
mainreleases through this.CHANGELOG.mdor not (it is optional, Adk Python has it. But if we want it, we also should decide if the first changelog entry is the current release, or we populate it with previous releases also)Testing Plan
Validated end to end on a scratch repository using the same config.
go test -race -mod=readonly -count=1 -shuffle=on workgreenNotes
feat!:would propose v3.0.0, but a Go major bump alsorequires moving the module path to
/v3, which the tool cannot do.