Skip to content

Dispatch downstream bumps on stable publish#1679

Open
rosetta-livekit-bot[bot] wants to merge 1 commit into
mainfrom
dory-convened-gushers
Open

Dispatch downstream bumps on stable publish#1679
rosetta-livekit-bot[bot] wants to merge 1 commit into
mainfrom
dory-convened-gushers

Conversation

@rosetta-livekit-bot
Copy link
Copy Markdown
Contributor

@rosetta-livekit-bot rosetta-livekit-bot Bot commented Jun 1, 2026

After a release/vX.Y.Z PR merges and PyPI publish succeeds, fires a repository_dispatch to TARGET_REPO so we can open a PR bumping the pinned livekit-agents version in downstream consumers (e.g. agent-starter-python).

Stability is inferred from the PR head ref pattern (release/vX.Y.Z), which mirrors the user's choice in the bump job (patch/minor/major/ promote produce X.Y.Z; *-rc variants produce X.Y.Z.rcN and are skipped). This avoids an unnecessary checkout and a version-string regex.

Republish retries are intentionally not dispatched here. Downstream sync workflow exposes a workflow_dispatch input for that case.

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Jun 1, 2026

⚠️ No Changeset found

Latest commit: 4fcd07d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot left a comment

Choose a reason for hiding this comment

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

Devin Review found 1 potential issue.

View 2 additional findings in Devin Review.

Open in Devin Review

Comment on lines +81 to +92
- name: Dispatch to internal-actions
if: steps.version.outputs.version != ''
env:
GH_TOKEN: ${{ secrets.SYNC_DISPATCH_TOKEN }}
TARGET_REPO: ${{ vars.TARGET_REPO }}
VERSION: ${{ steps.version.outputs.version }}
run: |
gh api -X POST "repos/${TARGET_REPO}/dispatches" \
-f event_type="livekit-agents-js-published" \
-f client_payload[version]="$VERSION" \
-f client_payload[source_repo]="${{ github.repository }}" \
-f client_payload[source_sha]="${{ github.sha }}"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🟡 Dispatch step failure prevents docs build and S3 upload

The new "Dispatch to internal-actions" step (line 81-92) is inserted before the "Build docs" and "S3 upload" steps. If the gh api call fails (e.g., SYNC_DISPATCH_TOKEN is expired/missing, TARGET_REPO is misconfigured, or a transient network error occurs), the job will fail at that step. Because the downstream docs steps at lines 93-98 use if: steps.changesets.outputs.published == 'true' (which does not include always()), GitHub Actions will skip them when the job is already in a failed state. This means an unrelated dispatch failure would block documentation from being published to S3.

Previously, nothing between the changesets action and the docs steps could fail the job. The fix is to either add continue-on-error: true to the dispatch step, move it after the docs/upload steps, or split it into a separate job.

Prompt for agents
The "Dispatch to internal-actions" step at line 81-92 of .github/workflows/release.yml is placed before the "Build docs" (line 93) and "S3 upload" (line 97) steps. If the gh api call fails, the job fails and docs/S3 upload are skipped. These are independent concerns that should not be coupled.

Possible fixes (pick one):
1. Move the dispatch step after the S3 upload step so docs are published regardless of dispatch outcome.
2. Add continue-on-error: true to the dispatch step so a failure is recorded but does not fail the job.
3. Split the dispatch into its own job with a needs: release dependency, so the main release job is unaffected.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

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.

0 participants