psyduckduck03/docs.coopcloud.tech
0
0
Fork 0
forked from toolshed/docs.coopcloud.tech
Code Issues Pull Requests Packages Projects Releases Wiki 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)
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
---
@ -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 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.
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
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
* rollback: same as above!
3) 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.
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