Issues/442 prod pipeline - #56
Conversation
|
Warning Review limit reached
Next review available in: 29 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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 ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request adds a manual production deployment workflow for ChangesProduction deployment
Dependency override updates
Estimated code review effort: 4 (Complex) | ~45 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant Maintainer
participant BuildJob as GitHub Actions build job
participant IaaS as shared iaas deployment logic
participant Artifact as GitHub artifact store
participant DeployJob as zsoftly-yow deployment job
participant Docs as docs site
Maintainer->>BuildJob: Dispatch with source_ref
BuildJob->>IaaS: Prepare and build selected release
BuildJob->>Artifact: Upload artifact and resolved commits
DeployJob->>Artifact: Download and install artifact
DeployJob->>IaaS: Run dry run and production deployment
IaaS->>Docs: Deploy documentation and run smoke test
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/40-deploy-prod.yml (1)
37-45: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
[ERROR]instead of[FAIL].These messages use
[FAIL]. The workflow guideline permits[ERROR], not[FAIL]. Replace each[FAIL]marker.Also applies to: 60-60, 163-164
🤖 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 @.github/workflows/40-deploy-prod.yml around lines 37 - 45, Update the validation error messages in the production deploy workflow, including the checks around SOURCE_REF and the additional occurrences at the referenced locations, to use the “[ERROR]” prefix instead of “[FAIL]”; keep the existing messages and validation behavior unchanged.Source: Coding guidelines
🤖 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 @.github/workflows/40-deploy-prod.yml:
- Around line 40-47: Update the production workflow validation around SOURCE_REF
to require immutable staging provenance, such as a staging promotion record,
workflow run, or commit SHA, and verify that the successful staging deployment
corresponds to the exact commit selected for production rather than only
validating a movable release/* branch. Update docs/release-process.md lines
30-31 to document promoting the exact validated commit; both listed sites
require changes.
- Around line 53-54: Update the build and deploy jobs in the workflow so the
IaaS repository revision is resolved to one commit SHA during the build, exposed
as a job output, and consumed by the deploy job. Replace the deploy job’s
IAAS_REF main reference with that immutable SHA and ensure checkout validates or
uses the same revision before running deployment scripts.
---
Nitpick comments:
In @.github/workflows/40-deploy-prod.yml:
- Around line 37-45: Update the validation error messages in the production
deploy workflow, including the checks around SOURCE_REF and the additional
occurrences at the referenced locations, to use the “[ERROR]” prefix instead of
“[FAIL]”; keep the existing messages and validation behavior unchanged.
🪄 Autofix
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: 5f269eb3-942b-49ee-8dab-7807fb97b9e2
📒 Files selected for processing (3)
.github/actionlint.yaml.github/workflows/40-deploy-prod.ymldocs/release-process.md
| if [[ "$SOURCE_REF" != release/* ]]; then | ||
| echo "[FAIL] source_ref must start with release/ (got: $SOURCE_REF)" | ||
| exit 1 | ||
| fi | ||
| if ! git check-ref-format --branch "$SOURCE_REF" >/dev/null 2>&1; then | ||
| echo "[FAIL] source_ref must be a valid branch name (got: $SOURCE_REF)" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Require immutable staging provenance before production deployment.
The workflow accepts any syntactically valid release/* branch. It does not verify a successful staging deployment or identify the staged commit. A branch ref can move after staging.
.github/workflows/40-deploy-prod.yml#L40-L47: require a staging promotion record, workflow run, or commit SHA, and verify that its successful staging deployment matches the commit selected for production.docs/release-process.md#L30-L31: document promotion of the exact validated commit instead of promotion of the same branch ref.
📍 Affects 2 files
.github/workflows/40-deploy-prod.yml#L40-L47(this comment)docs/release-process.md#L30-L31
🤖 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 @.github/workflows/40-deploy-prod.yml around lines 40 - 47, Update the
production workflow validation around SOURCE_REF to require immutable staging
provenance, such as a staging promotion record, workflow run, or commit SHA, and
verify that the successful staging deployment corresponds to the exact commit
selected for production rather than only validating a movable release/* branch.
Update docs/release-process.md lines 30-31 to document promoting the exact
validated commit; both listed sites require changes.
|
Addressed the actionable workflow comments in this branch:
For the staging provenance suggestion: the workflow now pins the selected release commit during prod and fails if the release branch moves between build and deploy. Verifying that the same commit came from a specific successful staging workflow run is a larger promotion-record feature, so I recommend tracking that separately instead of expanding this PR. |
Run the shared iaas deploy script with PHASE=dry_run before the real production deploy while keeping the public docs build on GitHub-hosted runners and deploy secrets on the YOW production job.
Adds the docs-owned production deployment workflow that builds a selected release ref on a clean runner, fetches the shared iaas deploy runner, runs dry-run before deploy, and documents the production release flow. Also keeps pnpm overrides in the existing package.json pattern while patching audit findings.
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 `@package.json`:
- Line 40: Narrow the package.json override selectors for brace-expansion and
postcss so they only target the tested compatible ranges, rather than forcing
older major-version consumers onto newer majors. Alternatively, upgrade the
dependent consumer packages first, then retain overrides only where
compatibility is established.
🪄 Autofix
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: 0c3664d1-c018-4ecf-9228-10ceb0f24518
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
.github/workflows/40-deploy-prod.ymldocs/release-process.mdpackage.json
🚧 Files skipped from review as they are similar to previous changes (2)
- docs/release-process.md
- .github/workflows/40-deploy-prod.yml
…es package.json pnpm.overrides, not a new workspace file.
1 participant
What changed
Why
Summary by CodeRabbit
New Features
Documentation
Security