Record Phase 4 deployment findings; resolve prod image placeholders - #1
Conversation
Nine CD failures surfaced constraints that existed nowhere in the repo. Documents them in docs/decisions.md so the next deploy doesn't rediscover them: - Federated credential subjects must use GitHub's immutable-ID form (repo:OWNER@id/REPO@id:...); the readable form fails with AADSTS700213. The Phase 4 entry claimed the readable form was registered, which was wrong. - SQL logical-server creation is gated per-region *per-subscription*; hence the separate sqlLocation param and the location-salted server name (a failed create tombstones the name-to-region pairing). - Contained DB users use WITH SID/TYPE = E to avoid a Directory Readers dependency this tenant can't grant. - The deployment-script image is Azure Linux, so go-sqlcmd replaces mssql-tools18. - The containerapp CLI extension shadows core and rejects valid revision names. - Key Vault purge protection cannot be set back to false. Also replaces the REPLACE_WITH_GH_OWNER placeholders in prod.bicepparam with the real GHCR owner, and corrects the stale production subject in cd.yml's deploy-prod placeholder comment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019UnusAvj1QtPwNnd28udLm
|
Warning Review limit reached
Next review available in: 49 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe changes document production deployment prerequisites and infrastructure constraints, and replace production GHCR image placeholders with the configured repository owner. ChangesDeployment operations
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@infra/params/prod.bicepparam`:
- Around line 13-17: Update the production deployment flow around apiImage and
workerImage so deployments receive explicit Git-SHA-tagged image values rather
than relying on :latest. Before enabling production, validate both effective
image parameters and fail the deployment if either ends with :latest; remove or
replace the mutable defaults in prod.bicepparam.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 827b96a4-1ed9-4157-a727-1d7e30ff4262
📒 Files selected for processing (3)
.github/workflows/cd.ymldocs/decisions.mdinfra/params/prod.bicepparam
| // `latest` is only the bootstrap value — cd.yml overrides both with the git-SHA tag at deploy | ||
| // time so a revision is always traceable to an exact commit. GHCR owner is lowercased because | ||
| // registry paths are case-sensitive while the GitHub account name (Affan2900) is not. | ||
| param apiImage = 'ghcr.io/affan2900/cognilens-api:latest' | ||
| param workerImage = 'ghcr.io/affan2900/cognilens-worker:latest' |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Do not let production deployments fall back to latest.
The comment says cd.yml overrides these values with SHA tags, but the production job is still commented out. A manual deployment using this parameter file therefore uses mutable latest, defeating traceability and allowing an unintended image to be released. Before enabling production, pass both SHA-tagged image parameters and fail if either effective image ends in :latest.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@infra/params/prod.bicepparam` around lines 13 - 17, Update the production
deployment flow around apiImage and workerImage so deployments receive explicit
Git-SHA-tagged image values rather than relying on :latest. Before enabling
production, validate both effective image parameters and fail the deployment if
either ends with :latest; remove or replace the mutable defaults in
prod.bicepparam.
The what-if step succeeded but the comment step died with "Argument list too long" (E2BIG) before its script ran. Step outputs reach the next step as environment variables, and execve() caps a single envp string at MAX_ARG_STRLEN (128 KB); the plan was ~250 KB. Write it to whatif.txt and read it in-process instead, which avoids exec entirely. Two further problems on the same path: - GitHub caps an issue comment body at 65536 characters, so the post would have failed with 422 even had the env var fit. Truncate to 60000, eliding the middle so the trailing "Resource changes: ..." summary survives. - `|| true` discarded the what-if exit code, so a genuinely broken template would post its error and still pass CI green. Capture the code and fail the job after the comment is posted. Also drops --no-pretty-print (raw JSON with full before/after bodies for every resource — larger and less readable than the default diff), silences ANSI colour via AZURE_CORE_NO_COLOR, and bumps github-script v7 -> v9 to clear the Node 20 deprecation warning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019UnusAvj1QtPwNnd28udLm
Azure what-if (rg-cognilens-dev)Show plan |
Record deployment findings; resolve prod image placeholders
What
Documents the constraints uncovered while getting
CD (dev)green, and clears two placeholders that would have broken the prod path later.docs/decisions.md— six new Phase 4 entries. Notably corrects a factually wrong claim: the existing entry stated the federated credentials trustrepo:Affan2900/cogniLens:ref:refs/heads/main. They don't — GitHub asserts an immutable-ID subject (repo:Affan2900@123811141/cognilens@1312175714:...), and the readable form fails every login withAADSTS700213.infra/params/prod.bicepparam— replacesREPLACE_WITH_GH_OWNERwith the real GHCR owner..github/workflows/cd.yml— corrects the stale:environment:productionsubject in thedeploy-prodplaceholder comment.Other findings recorded: per-subscription SQL region gating (and why
sqlServerNameis salted withsqlLocation), SID-based contained DB users,go-sqlcmdovermssql-tools18, thecontainerappextension shadowing core azure-cli, and one-way Key Vault purge protection.Why this PR exists
ci.ymlhas never executed — every change so far went straight tomain, and it only triggers onpull_request. This is the first run of build / format check / tests / Trivy / what-if, and the first use of the:pull_requestfederated credential. Expect the CI result here to be informative regardless of whether it passes.Verification
az bicep build-params --file infra/params/prod.bicepparamcompiles clean (the twono-hardcoded-env-urlswarnings insql.bicepare pre-existing).No behavioural change to the dev deploy path — the what-if plan on this PR should show no diff.
🤖 Generated with Claude Code
https://claude.ai/code/session_019UnusAvj1QtPwNnd28udLm
Summary by CodeRabbit
Deployment
Documentation