This repository was archived by the owner on Oct 28, 2026. It is now read-only.
Repository navigation
Add a mode that deploys the staging tree as it stands - #29
Merged
Merged
Conversation
The escape hatch for work that never came from a ref: a file edited directly on staging, a patch applied by hand, a checkout repaired in place. "Sync staging" (/deployments/sync) carries no line items and does no git work at all — the plan is the full-tree rsync plus the same canary gate and depool/repool rollout every other deployment gets. The pipeline needed almost nothing for it: syncPlanFor() returns a full-tree plan for the new intent, and with no refs the preparation steps fall away on their own. The wizard drops its selection step rather than showing an empty picker, and the server refuses submitted items under this intent instead of ignoring them. Gated on its own permission (deploy.sync_staging) rather than the per-repository deploy grants, because it is not scoped to a repository: it ships whatever anyone else has staged too. Checked in both places, as everything else is — the form and DeploymentAuthorizer. Seeded for ops and mediawiki-admins. Recording no refs also means no undo point, so rollback is not offered afterwards and a failed sync enqueues none: nothing about the staging tree was changed by the deployment, so there is nothing to undo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QKzD8eUV1sT45NMNnjKSAg
|
Warning Review limit reachedNext included review available in 10 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (19)
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 |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The escape hatch for work that never came from a ref: a file edited directly on staging, a patch applied by hand, a checkout repaired in place.
Sync staging (
/deployments/sync) deploys/srv/mediawiki-stagingexactly as it is on disk — no fetch, no checkout, nothing selected. The plan is the full-treersync-local, thenrsync-remoteper appserver, with the same staging canary gate, per-server canary, l10n option and depool/repool rollout every other deployment gets. Two-step wizard (options → review), since there is nothing to pick.How it works
The pipeline needed almost no special-casing.
ShimCalls::syncPlanFor()returns a full-tree plan for the newDeploymentIntent::SyncStaging, and with no line items the git and patch preparation steps fall away on their own. Planner and runner still go through that one method, so the reviewed plan is literally what runs.The wizard drops its selection step rather than rendering an empty picker, and the server refuses submitted
itemsunder this intent (prohibited) instead of silently ignoring them.Permissions
Gated on its own permission,
deploy.sync_staging, rather than the per-type deploy grants — it is not scoped to a repository, so it ships whatever anyone else has staged too. Enforced in both places as everything else here is:StoreDeploymentRequest+DeploymentPolicyfor the form,DeploymentAuthorizerfor the job. Seeded foropsandmediawiki-admins; existing installs pick it up by re-running the seeder.Staging-only is still offered for a sync (it updates the production tree on the staging host and runs its canary, without touching appservers), so an account without
deploy.production_serverscan use the mode in that limited form — consistent with how the other intents treat that permission.No undo point
Recording no refs means no snapshot, so rollback is not offered afterwards and a failed sync enqueues none: the deployment never changed the staging tree, so there is nothing to undo. Both the wizard and the run screen say so, and the history row reads "Synced /srv/mediawiki-staging as it stood" rather than showing an empty line-item list.
Verification
New
tests/Feature/SyncStagingTest.php, 12 tests: whole-tree rsync with no--path, never touches git, canary still gates the rollout, staging-only stops after the local sync, no rollback on failure, the three wizard endpoints, items refused, and both halves of the permission check.Full suite 236/236 green, Pint clean,
npm run buildsucceeds.Generated by Claude Code