ci: deploy production inline from release-please (fix missing release tag trigger)#708
Merged
Merged
Conversation
…gger) release-please creates the GitHub release + tag using the default GITHUB_TOKEN. GitHub does not emit workflow-triggering events for actions taken with GITHUB_TOKEN (recursive-trigger block), so the `release: published` event never reached CD (Production) and nothing deployed after a release PR merged. Make CD (Production) a reusable workflow (workflow_call) accepting a tag_name input, and have release-please invoke it inline when it reports release_created == true. Running the deploy as a job in the same workflow run sidesteps the GITHUB_TOKEN cascade restriction entirely — no PAT required. - CD_production: add workflow_call trigger; resolve the deploy tag from inputs.tag_name (call) or github.event.release.tag_name (event) via a job-level DEPLOY_TAG env; keep the version-shape guard and the refs/tags checkout. The `release: published` trigger is retained as a fallback for releases published via the UI or a PAT. - release-please: expose release_created/tag_name outputs and add a deploy-production job (uses: ./.github/workflows/CD_production.yml, secrets: inherit) gated on release_created. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes production deployments not triggering after a release-please merge by running the production deploy inline within the same release-please workflow run (avoiding GitHub’s event suppression for actions performed with GITHUB_TOKEN).
Changes:
- Expose
release_createdandtag_namefrom therelease-pleasejob and conditionally invoke production deployment via a reusable workflow. - Convert
CD_production.ymlinto a reusable workflow (workflow_call) that accepts atag_nameinput while keepingrelease: publishedas a fallback trigger. - Standardize production deploy tag resolution via a
DEPLOY_TAGenv var used for validation, checkout ref, andAPP_VERSION.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| .github/workflows/release-please.yml | Adds job outputs and a gated deploy-production reusable-workflow call after a release is created. |
| .github/workflows/CD_production.yml | Adds workflow_call support and routes deployment to a resolved DEPLOY_TAG used throughout the job. |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
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
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.
Why
After merging staging → production, release-please opens its release PR and (on merge) creates the GitHub release + tag — but CD (Production) never runs.
Root cause: release-please creates the release/tag with the default
GITHUB_TOKEN. GitHub deliberately does not emit workflow-triggering events for actions taken withGITHUB_TOKEN(recursive-trigger protection). So therelease: publishedevent never reaches CD (Production), and nothing deploys.How
Run the deploy as a job in the same workflow run as release-please, which sidesteps the cascade restriction — no PAT needed.
workflow_calltrigger with atag_nameinput.DEPLOY_TAG = inputs.tag_name || github.event.release.tag_name, used by the validate step, therefs/tags/…checkout, andAPP_VERSION.if:+ regex step).release: publishedas a fallback for releases published via the UI or a PAT.release_created/tag_nameoutputs and add adeploy-productionjob thatuses: ./.github/workflows/CD_production.ymlwithsecrets: inherit, gated onrelease_created == 'true'.Flow after this
deploy-productionjob deploys it in the same run.Notes
release: publisheddoes not fire; only the inline call deploys. A manual UI/PAT release fires the fallback path instead.productionenvironment protection rules still apply to the called job.