Skip to content

chore: scope v4 branch workflows to v4#52

Merged
aaron-zeisler merged 2 commits into
v4from
aaronz/SDK-2119/release-please-v4-trigger
May 27, 2026
Merged

chore: scope v4 branch workflows to v4#52
aaron-zeisler merged 2 commits into
v4from
aaronz/SDK-2119/release-please-v4-trigger

Conversation

@aaron-zeisler
Copy link
Copy Markdown

@aaron-zeisler aaron-zeisler commented May 26, 2026

Summary

Configure the new v4 branch's GitHub Actions workflows for the v4 release line. This PR targets v4 and introduces no changes to v3v3 stays frozen at its current HEAD.

Three files change:

  1. release-please.yml — trigger on push to v4, with target-branch hardcoded to v4. (See "Why hardcoded v4" below.)
  2. ci.ymlpush and pull_request triggers scoped to [v4, feat/**]. v3 PRs/pushes read v3's ci.yml, so listing v3 here on v4 would be dead config.
  3. check-go-versions.yml — matrix kept at ["v3", "v4"]. This is an intentional cross-reference: after the eventual default-branch flip to v4, this scheduled workflow runs from v4, and the matrix tells it to keep opening Go-version-bump PRs against both branches during v3's deprecation window.

This is one of three parallel PRs across go-jsonstream, go-sdk-common, and go-server-sdk-evaluation. Same change pattern in each.

Why this PR exists

Bundled per Matthew's feedback on the original release-please.yml-only revision: keeps all "set up v4 GHA" work in one PR rather than splitting across multiple. Most importantly, without the ci.yml change the v4 transition PRs in the next stage would have no Go-test signal at PR time — only the external bot checks (Bugbot, UPRA, Semgrep) would gate them.

Why hardcoded v4 and not omitted, and not ${{ github.ref_name }}

An earlier revision of this PR dropped target-branch entirely, on the understanding that the action would auto-detect from the triggering ref. It does not — it falls back to the repo's default branch (release-please-action#913, open since Dec 2023). For us today the default is v3, so omitting target-branch would silently route v4 release PRs to v3.

A later revision used target-branch: ${{ github.ref_name }}. That works for push events — restricted here to v4 by on.push.branches — but workflow_dispatch ignores on.push.branches. A manual run from any branch carrying this workflow file (e.g., a feature branch forked from v4) would resolve github.ref_name to that branch and try to open a release PR against it. Hardcoded v4 closes that gap and matches v3's existing pattern (v3's copy hardcodes target-branch: v3).

Context

Part of the EasyJSON removal effort on SDK-2113, shipping as v4 of these three libraries per semver. Tracked under SDK-2119. Once this lands, the next step is to rebase the existing EasyJSON-removal PR (#39) onto v4.

Test plan

  • YAML lints clean
  • Confirmed: Go-test CI workflows are gated by ci.yml's branch filter; this PR is YAML-only with no Go-code surface to validate. External checks (Bugbot, UPRA, Do Not Merge, Semgrep) still run.

via LD Research 🤖

@aaron-zeisler aaron-zeisler requested a review from a team as a code owner May 26, 2026 19:08
@aaron-zeisler aaron-zeisler force-pushed the aaronz/SDK-2119/release-please-v4-trigger branch from 930ead0 to 0471fdf Compare May 26, 2026 19:16
@aaron-zeisler aaron-zeisler changed the title chore: add v4 to release-please workflow trigger chore: add v4 to release-please trigger and drop hardcoded target-branch May 26, 2026
Comment thread .github/workflows/release-please.yml
@aaron-zeisler aaron-zeisler force-pushed the aaronz/SDK-2119/release-please-v4-trigger branch from 0471fdf to 1c8182e Compare May 26, 2026 19:30
@aaron-zeisler aaron-zeisler changed the title chore: add v4 to release-please trigger and drop hardcoded target-branch chore: add v4 to release-please trigger and use dynamic target-branch May 26, 2026
@aaron-zeisler aaron-zeisler force-pushed the aaronz/SDK-2119/release-please-v4-trigger branch from 1c8182e to 7b91664 Compare May 26, 2026 19:59
@aaron-zeisler aaron-zeisler changed the title chore: add v4 to release-please trigger and use dynamic target-branch chore: teach v4 branch to all release & CI workflows May 26, 2026
Comment thread .github/workflows/release-please.yml Outdated
@aaron-zeisler aaron-zeisler changed the base branch from v3 to v4 May 26, 2026 20:10
…versions)

Configures the v4 branch's GitHub Actions workflows for the v4
release line, dropping v3 references where they would be dead config
on this branch. Specifically, on v4:

- release-please.yml: trigger on push to v4 only. target-branch stays
  as ${{ github.ref_name }} for robustness if more branches are added
  later. (Auto-detection is broken — see
  googleapis/release-please-action#913 — so
  the explicit dynamic value is still the safe choice.)
- ci.yml: push and pull_request triggers scoped to [v4, feat/**].
  v3 PRs/pushes read v3's ci.yml, so listing v3 here on v4 would
  be dead config.
- check-go-versions.yml: matrix kept at ["v3", "v4"]. This is an
  intentional cross-reference: after the eventual default-branch
  flip to v4, this workflow runs from v4 and the matrix tells it to
  keep opening Go-version-bump PRs against both branches during v3
  's deprecation window.

Bundled per Matthew's feedback: keeps all "set up v4 GHA" work in
one PR. v3 stays frozen at its current HEAD; this PR introduces no
changes to v3.

Part of the SDK-2119 EasyJSON removal project, which is shipping as
a v4 major version per semver.

Co-authored-by: Cursor <cursoragent@cursor.com>
@aaron-zeisler aaron-zeisler force-pushed the aaronz/SDK-2119/release-please-v4-trigger branch from 7b91664 to f3c7249 Compare May 26, 2026 20:14
@aaron-zeisler aaron-zeisler changed the title chore: teach v4 branch to all release & CI workflows chore: scope v4 branch workflows to v4 (cross-maintain Go versions) May 26, 2026
Comment thread .github/workflows/ci.yml
on:
push:
branches: [ 'v3', 'feat/**' ]
branches: [ 'v4', 'feat/**' ]
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI workflow drops v3 branch instead of adding v4

High Severity

The push and pull_request branch filters replace v3 with v4 instead of adding v4 alongside v3. This removes CI coverage for the existing v3 branch entirely. The PR description explicitly states the intent is to "add v4 to the branch lists," and check-go-versions.yml correctly uses ["v3", "v4"] — but here v3 is dropped. The branches list needs to include both 'v3' and 'v4'.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit f3c7249. Configure here.

push:
branches:
- v3
- v4
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Release-please workflow drops v3 branch trigger entirely

High Severity

The push trigger replaces v3 with v4 instead of listing both branches. The PR description says "add v4 to the push trigger… so a single workflow file correctly handles both v3 and v4," and the target-branch: ${{ github.ref_name }} change was specifically designed to support multiple branches dynamically. With only v4 in the trigger, release-please will never fire for v3 pushes.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit f3c7249. Configure here.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a per-branch workflow file. It lives on the v4 branch, and on push events GitHub Actions reads the workflow file from the branch being pushed to.

I've updated the PR description to reduce confusion.

@aaron-zeisler aaron-zeisler changed the title chore: scope v4 branch workflows to v4 (cross-maintain Go versions) chore: scope v4 branch workflows to v4 May 26, 2026
This workflow file lives only on the v4 branch (its push trigger is
restricted to v4), so the dynamic `target-branch: ${{ github.ref_name }}`
adds no flexibility — but it does open a workflow_dispatch footgun: a
manual dispatch from any branch carrying this file (e.g., a feature
branch forked from v4) would pass that branch's name to release-please,
potentially creating a release PR against an unintended branch.

Hardcoding `target-branch: v4` locks every push and every manual
dispatch of this v4-branch workflow to the v4 release line, matching
v3's existing hardcoded pattern.

The v3 branch's release-please.yml is unchanged and continues to use
`target-branch: v3`.

Co-authored-by: Cursor <cursoragent@cursor.com>
Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit d49d3d2. Configure here.

- uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
with:
target-branch: v3
target-branch: v4
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded target-branch contradicts stated dynamic intent

Low Severity

The PR description explicitly states target-branch is set to ${{ github.ref_name }} for robustness, citing the release-please-action#913 auto-detection bug and the hcloud-go pattern as justification. However, the actual code hardcodes target-branch: v4 instead of using the dynamic expression. While functionally equivalent today (the workflow only triggers on v4), this doesn't deliver the stated robustness benefit if additional release branches are added later.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit d49d3d2. Configure here.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above re: per-branch workflows and updating the PR description.

aaron-zeisler added a commit that referenced this pull request May 26, 2026
Transitions go-sdk-common to its v4 major version per Go's semantic
import versioning. With easyjson removed in the prior commit, this is
the natural moment to take the major bump.

Changes in this commit:
- go.mod: module path /v3 -> /v4; go-jsonstream pinned at /v4 dev
  pseudo-version
- All .go files: import paths /v3 -> /v4 for both go-sdk-common's own
  internal packages and go-jsonstream
- README.md: pkg.go.dev link and version-pairing prose updated
  (4.x of go-sdk-common pairs with 7.x of go-server-sdk)
- .release-please-manifest.json: 3.5.0 -> 4.0.0

Workflow file (release-please.yml, ci.yml, check-go-versions.yml)
changes for v4 are landing in #52 separately.

Part of the SDK-2113 EasyJSON removal project, shipping these libraries
as v4 majors per the v3 -> v4 strategy.

Co-authored-by: Cursor <cursoragent@cursor.com>
@aaron-zeisler aaron-zeisler merged commit 4a24959 into v4 May 27, 2026
19 checks passed
@aaron-zeisler aaron-zeisler deleted the aaronz/SDK-2119/release-please-v4-trigger branch May 27, 2026 16:50
aaron-zeisler added a commit that referenced this pull request May 28, 2026
Transitions go-sdk-common to its v4 major version per Go's semantic
import versioning. With easyjson removed in the prior commit, this is
the natural moment to take the major bump.

Changes in this commit:
- go.mod: module path /v3 -> /v4; go-jsonstream pinned at /v4 dev
  pseudo-version
- All .go files: import paths /v3 -> /v4 for both go-sdk-common's own
  internal packages and go-jsonstream
- README.md: pkg.go.dev link and version-pairing prose updated
  (4.x of go-sdk-common pairs with 7.x of go-server-sdk)
- .release-please-manifest.json: 3.5.0 -> 4.0.0

Workflow file (release-please.yml, ci.yml, check-go-versions.yml)
changes for v4 are landing in #52 separately.

Part of the SDK-2113 EasyJSON removal project, shipping these libraries
as v4 majors per the v3 -> v4 strategy.

Co-authored-by: Cursor <cursoragent@cursor.com>
aaron-zeisler added a commit that referenced this pull request May 28, 2026
Transitions go-sdk-common to its v4 major version per Go's semantic
import versioning. With easyjson removed in the prior commit, this is
the natural moment to take the major bump.

Changes in this commit:
- go.mod: module path /v3 -> /v4; go-jsonstream pinned at /v4 dev
  pseudo-version
- All .go files: import paths /v3 -> /v4 for both go-sdk-common's own
  internal packages and go-jsonstream
- README.md: pkg.go.dev link and version-pairing prose updated
  (4.x of go-sdk-common pairs with 7.x of go-server-sdk)
- .release-please-manifest.json: 3.5.0 -> 4.0.0

Workflow file (release-please.yml, ci.yml, check-go-versions.yml)
changes for v4 are landing in #52 separately.

Part of the SDK-2113 EasyJSON removal project, shipping these libraries
as v4 majors per the v3 -> v4 strategy.

Co-authored-by: Cursor <cursoragent@cursor.com>
aaron-zeisler added a commit that referenced this pull request May 28, 2026
- Remove easyjson implementation — drops the optional easyjson backend, removes the easyjson conversion files for `ldcontext` / `ldreason` / `ldvalue`, and bumps `go-jsonstream` to a version that has its own easyjson removal merged.
- Bump module path to v4 — bumps the module path `/v3` → `/v4`, rewrites all internal imports, bumps `go-jsonstream` from `/v3` to `/v4`. Workflow file changes for v4 landed separately in [#52](#52).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants