Skip to content

fix: add code-carry merge step to release-please workflow#175

Merged
ankitTelnyx merged 1 commit into
masterfrom
fix/add-code-carry-merge-step
Jun 18, 2026
Merged

fix: add code-carry merge step to release-please workflow#175
ankitTelnyx merged 1 commit into
masterfrom
fix/add-code-carry-merge-step

Conversation

@ankitTelnyx

Copy link
Copy Markdown
Collaborator

Problem

release-please creates PRs with only version bumps (CHANGELOG, build.gradle.kts, README). The actual SDK code changes on next were never included in the release PR.

Result: PR #174 has only 4 files — no SDK code. Merging it would publish a Maven artifact with the new version number but old code.

Fix

Adds a "Merge next code into release PR" step (same as PR #440 on telnyx-node):

  1. After release-please creates the PR, this step merges next into the release PR branch
  2. Uses pr_number output directly from release-please (avoids GitHub API race condition)
  3. Falls back to gh pr list with 3 retries (5s interval)
  4. -X ours on conflicts prefers release-please's version bumps

Evidence

Parity

Same pattern as TypeScript SDK (telnyx-node PR #437 + #440).

release-please creates PRs with only version bumps (CHANGELOG,
build.gradle.kts, README). The actual SDK code changes on `next` were
never included in the release PR, so master got version bumps without
code changes.

This adds a 'Merge next code into release PR' step that merges `next`
into the release PR branch after release-please creates it. Uses the
pr_number output directly (with retry fallback) to avoid GitHub API
eventual-consistency race conditions.

Same fix as PR #440 on telnyx-node.
@ankitTelnyx ankitTelnyx merged commit 24d7ded into master Jun 18, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant