ci(release): close notification/payment path gaps; build payment-service image - #569
Open
izzywdev wants to merge 1 commit into
Open
ci(release): close notification/payment path gaps; build payment-service image#569izzywdev wants to merge 1 commit into
izzywdev wants to merge 1 commit into
Conversation
…ice image Two related fixes to the release pipeline, no app-logic change. 1. release.yml's push-path filter was missing services/notification-service/** and services/payment-service/**. This is the same silent-ship gap the file already documents for chat-service: a change confined to one of those service dirs would merge green and never trigger a release, shipping stale (or, for payment-service, no) image. Added both paths. 2. payment-service had no build step, so its image never existed and paymentService.image.tag sat at "" (InvalidImageName if ever enabled). Added a Build & push payment-service step (self-contained context, like clock-app) and wired it through the GitOps tag-bump guard: PAYMENT_OK, the EXPECTED count, the awk payment var, and the repository anchor — per the bump step's own rule that a new build step MUST add its anchor and count. Verified by simulating the awk against values-prod.yaml: payment's tag rewrites and COUNT stays consistent whether or not the build succeeds. payment-service stays enabled: false. This only makes the image EXIST so a future go-live is a values flip in a deploy window, not a missing-image scramble. The build is continue-on-error, so a payment build failure is non-fatal and leaves its tag pinned rather than breaking the release. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hc8XVgyLJkyeMsRysJYCqP
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
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.
📋 Description
Two related fixes to the release pipeline, batched. No app-logic change, and payment-service stays
enabled: false— this only makes its image exist so a future go-live is a values flip, not a missing-image scramble. Follow-up to #565.🔄 Type of Change
🔧 Implementation Details
1. Missing release-trigger paths
release.yml'spush.pathslistedservices/{email,sms,provisioning,billing,chat}-service/**but notnotification-service/**orpayment-service/**— the exact silent-ship gap the file already documents for chat-service (a change confined to one of those dirs merges green and never rebuilds the image). Added both.2. payment-service was never built
It had no build step, so its image never existed and
paymentService.image.tagsat at""(→InvalidImageNameif ever enabled). Added a Build & push payment-service step (self-contained context, like clock-app) and wired it through the GitOps tag-bump guard:PAYMENT_OK, theEXPECTEDcount, theawk paymentvar, and the repository anchor — exactly as the bump step's own comment demands when a build step is added.🧪 Testing
release.ymlparses as YAML.awkagainst the realvalues-prod.yaml: with all builds succeeding it rewrites 12 tags (2 + 10gated services), matching the newEXPECTED; payment'stag: ""correctly becomes the SHA. If the payment build fails (continue-on-error), its anchor is guarded off andCOUNTstill equalsEXPECTED, so the guard holds either way.docker buildin this sandbox (no daemon). Payment's build iscontinue-on-error, so a failure is non-fatal — it leaves the tag pinned rather than breaking the release.📝 Deployment Notes
release.yml), which builds payment-service and bumps its tag off"". payment-service still won't render —enabled: false. Enabling it remains a separate deploy-window decision (needs Stripe secrets + product sign-off).Generated by Claude Code