sloanops.admin/3031023-xyz-public
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify CMS back-sync boundary

Browse Source
This commit is contained in:
Kevin
2026-09-04 22:30:00 -04:00
parent e42d281b9a
commit 2f48055ce7
3 changed files with 12 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/decap-cms-pilot.md
+6 -5
View File
@@ -267,9 +267,10 @@ Because Decap writes to a fixed `cms` branch, SloanOps creates the pull request
from `cms` to `main` in Gitea. Internal CMS application/configuration changes
start from the current `cms` state, enter protected `cms` through an
operator-reviewed pull request, and are then promoted with the staged content.
After an approved `main` merge, synchronize its merge commit back into `cms`
through a protected-branch pull request before the next editing cycle. Do not
automate production merge.
After an approved `main` merge, synchronize only file changes that are missing
from `cms` through a protected-branch pull request. When the `main` merge commit
has the same tree as `cms`, no no-op sync is required. Do not automate
production merge.
The accepted pilot is promoted by replacing the disposable branch with the
permanent, slash-free `cms` branch. It remains a preview/staging branch and
@@ -285,8 +286,8 @@ retains the same pull-request, validation, and approval path into `main`.
4. Review the complete staged diff and open `cms` to `main`.
5. Require the stable secret-free validation status and SloanOps approval.
6. Merge deliberately and confirm the affected production Worker jobs pass.
7. Synchronize the resulting `main` merge commit back into protected `cms`
before another editing cycle.
7. Synchronize `main` back into protected `cms` only when it contains file
changes absent from `cms`; skip a no-op history-only merge.
## Test matrix