p4u1/docs.coopcloud.tech
0
0
Fork 0
forked from toolshed/docs.coopcloud.tech
Code Pull Requests Activity

fix: quotes

Browse Source
This commit is contained in:
decentral1se
2023-10-14 10:26:22 +02:00
parent 17bce5a4f3
commit 3f2ab68ada
1 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/federation/resolutions/in-progress/013.md
View File

@ -13,7 +13,7 @@ With this proposal, we would like to address the synchronisation of app deployme
### Details (Budget 007) ### Details (Budget 007)
We support a config file ($ABRA_DIR/config.yml) which has these defaults: We support a config file (`$ABRA_DIR/config.yml`) which has these defaults:
```yaml ```yaml
--- ---
@ -48,23 +48,23 @@ When `abra app deploy/upgrade/rollback/sync` is run, here's what we do:
* if there are changes, pull them in & log them * 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 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. `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.
The way to avoid merge conflicts will be to never move the OPERATOR_SYNC_VERSION env var (see below) from the line it is on in the app env config. `abra` will always insert it just under the TYPE env var. The way to avoid merge conflicts will be to never move the `OPERATOR_SYNC_VERSION` env var (see below) from the line it is on in the app env config. `abra` will always insert it just under the `TYPE` env var.
The initial implementation asks operators to initialise their own Git repositories. The initial implementation asks operators to initialise their own Git repositories.
2) Read the OPERATOR_SYNC_VERSION env var as the version to deploy / upgrade from / rollback from 2) 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 * upgrade: if deployed version does not match `OPERATOR_SYNC_VERSION`, warn before overview
* rollback: same as above! * rollback: same as above!
3) Run the deployment 3) Run the deployment
* if successful, record a new OPERATOR_SYNC_VERSION, commit & push the changes * 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 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. If `--chaos` is passed, we use the short commit hash instead of the version label.
Here's an example of the OPERATOR_SYNC_VERSION env var: Here's an example of the `OPERATOR_SYNC_VERSION` env var:
``` ```
# in ~/.abra/servers/example.com/matrix.example.com.env # in ~/.abra/servers/example.com/matrix.example.com.env