Dispatch downstream version bumps on stable publish#5817
Conversation
After a release/vX.Y.Z PR merges and PyPI publish succeeds, fires a repository_dispatch to TARGET_REPO so internal-actions 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 — the internal-actions sync workflow exposes a workflow_dispatch input for that case.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| -f event_type="livekit-agents-published" \ | ||
| -f client_payload[version]="$VERSION" \ | ||
| -f client_payload[source_repo]="${{ github.repository }}" \ | ||
| -f client_payload[source_sha]="${{ github.sha }}" |
There was a problem hiding this comment.
🔴 github.sha sends temporary merge commit SHA instead of actual merge commit SHA
In the dispatch-downstream-bumps job, ${{ github.sha }} is used for source_sha in the dispatch payload. For pull_request events, github.sha resolves to the temporary merge commit on refs/pull/<number>/merge, not the actual merge commit on the base branch. This temporary ref can be garbage-collected by GitHub. Every other place in this workflow that references the commit SHA for a merged PR uses github.event.pull_request.merge_commit_sha instead (publish.yml:150, publish.yml:190, publish.yml:255). The downstream consumer would receive a potentially-ephemeral SHA that doesn't correspond to any permanent commit on the target branch.
| -f client_payload[source_sha]="${{ github.sha }}" | |
| -f client_payload[source_sha]="${{ github.event.pull_request.merge_commit_sha }}" |
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
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.