ci: trigger CD (Production) on release publish#700
Merged
Conversation
Switch the workflow trigger from push of v*.*.* tags to the GitHub release `published` event so production only deploys when a release is actually cut (e.g. via release-please), not on every matching tag push. Check out the release tag explicitly and use github.event.release.tag_name for APP_VERSION since github.ref on a release event points to the default branch, not the tag. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the production CD workflow to deploy only when a GitHub Release is published (instead of on any matching tag push), aligning production deploys with the repository’s release-publishing flow.
Changes:
- Switch workflow trigger from
push.tagstorelease: types: [published]. - Ensure the deploy checks out the release’s tag and uses it as
APP_VERSION.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c394ca556f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Preserve the safety rail the previous push.tags trigger provided. A release.published event will fire for any tag, so add: - job-level if: startsWith(tag, 'v') as a cheap pre-filter - first-step bash regex (^v[0-9]+\.[0-9]+\.[0-9]+(-.+|[a-z].*)?$) that fails the run on a mismatch Matches the original v*.*.*, v*.*.*-*, v*.*.*[a-z]* patterns so an ad-hoc release on a non-version tag no longer deploys to production. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
actions/checkout's ref accepts ambiguous short names. If a branch were ever created with the same name as a release tag, the deploy would check out the branch instead of the tagged commit. Use the fully-qualified refs/tags/<tag> form to remove the ambiguity. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.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
v*.*.*tag. Tags can land before a release is cut (or via dependabot/manual pushes), which deployed prematurely.How
push.tags→release: types: [published].ref: \${{ github.event.release.tag_name }}so the deploy uses the tagged commit (onreleaseevents,github.refpoints to the default branch, not the tag).APP_VERSIONenv switched fromgithub.ref_name→github.event.release.tag_name.Notes
production/hotfix/v*, so the new trigger fires there.