Repository navigation
ci: publish on tag push so releases stop needing a manual dispatch - #196
Conversation
`on: release: [published]` can never fire for our releases. release-please creates the GitHub Release with GITHUB_TOKEN, and GitHub deliberately blocks GITHUB_TOKEN-raised events from starting further workflow runs (the recursion guard). v1.11.0 was tagged and released at 22:27 with zero publish runs; PyPI stayed on 1.10.1 until the workflow was dispatched by hand. Tag pushes are not subject to that guard, so `push: tags: ['v*']` makes the release self-publishing. The release and workflow_dispatch triggers are kept for human-published releases and as a fallback; both upload steps already set skip-existing: true, so a double trigger is a no-op rather than a failure. Tag resolution now also falls back to github.ref_name, which is the tag name on a push event (the release/dispatch paths supply it via other contexts). Closes #190
|
Warning Review limit reached
Next review available in: 21 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
) Closes #190. Closes #197. `release: published` never fired for an automated release, and #196's `push: tags` fix did not help: GitHub's recursion guard keys off the token that raised the event, not the event type. release-please pushes the tag and creates the release with GITHUB_TOKEN, so both triggers are inert. v1.11.1 confirmed this - tag created, zero publish runs. Use the one documented exception instead: "workflow_dispatch and repository_dispatch events always create workflow runs" even from GITHUB_TOKEN. release.yml now dispatches the publish workflow, gated on release-please's own `release_created` output and passing its `tag_name`, so publish runs only when a release was actually cut and always knows exactly which version it is shipping. Tag resolution is rewritten to read the source matching the event rather than coalescing all three. The old `a || b || c` chain would silently resolve a dispatch with an empty input to `main` and publish whatever HEAD happened to be; every failure path now aborts loudly instead. For #197, the TestPyPI smoke test retries 6 times with 15/30/60/60/60s backoff (~3m45s, was 5x15s), and only retries index-lag errors - any other pip failure is a real defect and fails immediately rather than burning the window. Co-authored-by: ptimizeroracle <git@binblok.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
1 participant
Fixes #190.
on: release: [published]can never fire for our releases. release-please creates the GitHub Release usingGITHUB_TOKEN, and GitHub deliberately blocksGITHUB_TOKEN-raised events from starting further workflow runs (the recursion guard).Observed on v1.11.0: release created at 22:27:07, zero
Release to PyPIruns. PyPI stayed on 1.10.1 until dispatched by hand. Every release has silently required a manual step, and if nobody notices, the tag and GitHub Release exist while PyPI quietly lags.Change
push: tags: ['v*']— tag pushes are not subject to theGITHUB_TOKENguard, so release-please's tag makes the publish self-triggering.release: [published](for human-published releases) andworkflow_dispatch(fallback).github.ref_name, which is the tag name on a push event.Double-trigger safety
Both upload steps already set
skip-existing: true, so if two triggers ever fire for the same version the second is a no-op rather than a 400. Theconcurrency: publish-pypigroup also serialises runs.This gets exercised immediately: merging the 1.11.1 release PR (#186) should now publish without any manual step.