docs: define release branch workflow#35
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughUpdated contribution and deployment documentation to direct contributions to ChangesContribution and deployment documentation
Estimated code review effort: 1 (Trivial) | ~3 minutes ✨ 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.
Code Review
This pull request updates the contribution and deployment documentation in CONTRIBUTING.md and README.md to introduce a new release branch workflow for Cloudflare production deployments. The reviewer identified a potential issue where automated content syncs to the main branch will not automatically propagate to the production site on the release branch, and suggested updating the auto-sync workflow or documenting how these updates are promoted.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| Semua kontribusi tetap masuk ke `main`. Rilis produksi dipromosikan oleh anggota | ||
| organisasi melalui pull request dari `main` ke `release`; jangan membuka pull | ||
| request kontribusi langsung ke `release`. |
There was a problem hiding this comment.
There is a workflow discrepancy between the new release branch deployment model and the automated content sync.
Currently, the Auto Sync workflow (described in lines 95-107) automatically commits updated data to main and deploys it. If the production site on Cloudflare tracks the release branch, these automated updates (which run every 6 hours) will not appear on the production site until a manual pull request from main to release is created and merged.
To resolve this, consider updating the auto-sync workflow to also handle promotion to release, or document how these automated updates are expected to reach production.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 86a7cf175b
ℹ️ 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".
| Semua kontribusi tetap masuk ke `main`. Rilis produksi dipromosikan oleh anggota | ||
| organisasi melalui pull request dari `main` ke `release`; jangan membuka pull | ||
| request kontribusi langsung ke `release`. |
There was a problem hiding this comment.
Align release instructions with active deploy triggers
I checked the repo-defined deployment paths: .github/workflows/deploy-pages.yml still deploys GitHub Pages only on pushes to main (lines 3-6), and sync-content.yml deploys only when github.ref == 'refs/heads/main' (lines 116-123). In that current setup, following this new main → release promotion instruction would not trigger any deployment, while pushes to main still would, so the documented production release path contradicts the active workflows unless the deployment configuration is updated alongside it.
Useful? React with 👍 / 👎.
Summary
mainreleasefor organization-managed Cloudflare production promotionmaintoreleasepull request flowValidation
npm run build(105 pages, 0 errors)Summary by CodeRabbit