ci: auto-merge release-please PRs - #454
Merged
Merged
Conversation
Triggers off the completion of the whole 'Release Please' workflow run (instead of pull_request events directly) so it always waits for the generate-readmes job's README commit to land on the release PR branch before merging. Delegates the actual merge to the reusable auto-merge-release.yml workflow in actions-nullplatform, using a GitHub App token so the downstream tag/GitHub Release still gets created (a merge with the default GITHUB_TOKEN wouldn't trigger it). Depends on nullplatform/actions-nullplatform#85 (pr_number input).
agustincelentano
approved these changes
Jul 29, 2026
2 tasks
sebastiancorrea81
added a commit
that referenced
this pull request
Jul 30, 2026
…flow_run (#455) The workflow_run-triggered version merged in #454 fails immediately with startup_failure (0 jobs ever scheduled) for reasons that aren't visible via the API — likely an org-level Actions policy restricting workflow_run, but that needs admin access to confirm. Switch back to the pull_request trigger proven to work in the other services-* repos, and instead solve the generate-readmes race with concurrency: cancel-in-progress keyed on the PR number. When the README-regeneration commit lands (observed ~38s after the release PR is opened, on a real release), it fires a new 'synchronize' event; GitHub cancels whatever older run for the same PR is still waiting on checks, so only the run for the final commit can ever reach the merge step. Co-authored-by: sebas_correa <sebastian.correa@nullplatform.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
auto-merge-release-pr, which auto-merges thechore(main): release x.y.zPR opened by release-please once its checks pass, using a GitHub App token (feat: add reusable auto-merge-release-pr workflow actions-nullplatform#83/chore(main): release 1.12.6 #84/fix(scope): Fixing typo in annotation in scope definition module #85) instead of the defaultGITHUB_TOKEN— a merge with the default token wouldn't trigger the downstream push-triggered release workflow that creates the tag/GitHub Release.release.ymlhas a second job (generate-readmes) that pushes an extra commit (regenerated READMEs) to the release PR branch after the PR is opened. Apull_request-triggered auto-merge could race and merge before that commit lands. To avoid that, this workflow triggers onworkflow_runcompletion of the wholeRelease Pleaseworkflow (both jobs), then looks up the open release PR itself and passes its number explicitly to the reusable workflow via the newpr_numberinput.Depends on
Compatibility notes
mainbranch protection here requires only thetrivy / Trivy IaC Scanstatus check, no reviews, no push restrictions — compatible with merging via the App token.release 6.7.1) has its checks stuck inaction_required(never approved) — unrelated to this change, but worth unblocking regardless.Test plan