diff --git a/docs/federation/resolutions/in-progress/013.md b/docs/federation/resolutions/in-progress/013.md index 67d1224..720aa21 100644 --- a/docs/federation/resolutions/in-progress/013.md +++ b/docs/federation/resolutions/in-progress/013.md @@ -45,8 +45,8 @@ There is also a new command `abra app sync ` which triggers a synchronis When `abra app deploy/upgrade/rollback/sync` is run, here's what we do: * `git pull` on the sync repository - * if there are changes, pull them in & log them - * if there is a merge conflict, bail out and ask operator to resolve them + * if there are changes, pull them in & log them + * if there is a merge conflict, bail out and ask operator to resolve them `abra` will search for Git repositories under `$ABRA_DIR/servers/...`. A single Git repository at the root (`$ABRA_DIR/servers/.git`) and on the individual server level (`$ABRA_DIR/servers/example.com/.git`) are supported. Both solution work alongside each other and symlinks are resolved. @@ -55,12 +55,12 @@ The way to avoid merge conflicts will be to never move the `OPERATOR_SYNC_VERSIO The initial implementation asks operators to initialise their own Git repositories. * Read the `OPERATOR_SYNC_VERSION` env var as the version to deploy / upgrade from / rollback from - * upgrade: if deployed version does not match `OPERATOR_SYNC_VERSION`, warn before overview - * rollback: same as above! + * upgrade: if deployed version does not match `OPERATOR_SYNC_VERSION`, warn before overview + * rollback: same as above! * Run the deployment - * if successful, record a new `OPERATOR_SYNC_VERSION`, commit & push the changes - * if unsuccessful, do not record a `OPERATOR_SYNC_VERSION` and ask operator to resolve + * if successful, record a new `OPERATOR_SYNC_VERSION`, commit & push the changes + * if unsuccessful, do not record a `OPERATOR_SYNC_VERSION` and ask operator to resolve If `--chaos` is passed, we use the short commit hash instead of the version label.