ci: make the release workflow retryable#3
Conversation
The v4.1.6 release run created the GitHub release but failed at the luarocks upload because LUAROCKS_TOKEN was empty, leaving no way to retry: re-running the job would abort on 'gh release create' since the release already exists, and the push trigger only fires on a rockspec change. - skip release creation when the release already exists - add a workflow_dispatch trigger taking the version as input, so a failed publish can be retried without a new rockspec commit - fail fast with a clear message when LUAROCKS_TOKEN is unavailable, rather than surfacing an opaque 'api/1//check_rockspec' API failure - fail fast when the rockspec for the version is missing
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 3 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: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Dropping the workflow_dispatch approach — re-triggering by amending the release commit on master and force-pushing instead. |
1 participant
The
v4.1.6release run (log) created the GitHub release and tag, then failed atluarocks upload:LUAROCKS_TOKENwas empty, so luarocks built the API URL asapi/1//check_rockspecand got an opaqueAPI failure.Root cause is environmental —
LUAROCKS_TOKENis an org-level secret that is granted toapi7/lua-resty-healthcheckbut not to this repository. That has to be fixed in the org settings.But the workflow also left no way to retry once that's done:
gh release create, becausev4.1.6already exists.pushtrigger only fires on arockspecs/**change, so there is nothing to re-trigger.Changes
gh release createwhen the release already exists.workflow_dispatchtrigger taking the version as input, so a failed publish can be retried without inventing a new rockspec commit.LUAROCKS_TOKENis empty, with a message naming the actual problem instead of theapi/1//check_rockspecsymptom.Recovering v4.1.6
LUAROCKS_TOKENto this repository.workflow_dispatchwith version4.1.6. The release already exists so it is skipped; only the luarocks upload runs.Template expansion stays confined to
env:blocks — no${{ }}inside anyrun:body.