WIP: operator collaboration #457

2024-12-29T19:59:38Z

decentral1se commented

2024-12-29 19:59:38 +00:00

RFC

OK, I'm not going for the "full automation from the start" approach. There were many great ideas explored on the ticket and elsewhere but I fear that established manual workflows might be radically different. I don't want to break those by bringing out some One True Automation Way implemented in abra?

So, this is the first step, the commands that allow you to (hopefully) do what you're already doing with /usr/bin/git but now with abra and a bit of convenience slapped on. Hopefully this allows us to figure out what we really need going ahead.

Two Git repo configs are supported.

"global" aka $ABRA_DIR/servers/.git
"server" aka $ABRA_DIR/servers/<server>/.git

Symlinks are honoured. You can also mix and match, apparently Git knows what to do! I've tested this briefly.

There are (so far) 2 new commands and they operate on specific apps. This is an attempt to minimise the merge conflict space while we get started.

abra app diff <domain> diffs the unstaged changes
abra app push <domain> commits/pushes changes (it diffs, asks for confirmation and a commit message (or pass --msg/-m))

It's possible to add/commit/push a single file while there are unstaged / untracked files elsewhere in the git repo.

This is already pretty useful due to toolshed/organising#625 (and further work). When you do a deploy/undeploy/upgrade/rollback, the version is written to the .env of the app.

However, when you git pull, this is for the whole git repo. So, my design starts to break down for pulling in changes from others 😭 Got any ideas? abra pull <repo>?

https://git.coopcloud.tech/coop-cloud/organising/issues/467 **RFC** OK, I'm not going for the "full automation from the start" approach. There were many great ideas explored on the ticket and elsewhere but I fear that established manual workflows might be radically different. I don't want to break those by bringing out some One True Automation Way implemented in `abra`? So, this is the first step, the commands that allow you to (hopefully) do what you're already doing with `/usr/bin/git` but now with `abra` and a bit of convenience slapped on. Hopefully this allows us to figure out what we really need going ahead. Two Git repo configs are supported. 1. "global" aka `$ABRA_DIR/servers/.git` 1. "server" aka `$ABRA_DIR/servers/<server>/.git` Symlinks are honoured. You can also mix and match, apparently Git knows what to do! I've tested this briefly. There are (so far) 2 new commands and they operate on specific apps. This is an attempt to minimise the merge conflict space while we get started. 1. `abra app diff <domain>` diffs the unstaged changes 1. `abra app push <domain>` commits/pushes changes (it diffs, asks for confirmation and a commit message (or pass `--msg/-m`)) It's possible to `add`/`commit`/`push` a single file while there are unstaged / untracked files elsewhere in the git repo. This is already pretty useful due to https://git.coopcloud.tech/toolshed/organising/issues/625 (and further work). When you do a `deploy`/`undeploy`/`upgrade`/`rollback`, the version is written to the `.env` of the app. However, when you `git pull`, this is for the whole git repo. So, my design starts to break down for pulling in changes from others 😭 *Got any ideas*? `abra pull <repo>`?

❤️ 1

decentral1se force-pushed opcollab1 from 2908ff0a9d to 4d7c812fe2

2024-12-29 23:46:46 +00:00

Compare

decentral1se referenced this pull request from toolshed/organising

2024-12-30 00:20:56 +00:00

Operator collaboration #467

yksflip commented

2024-12-30 13:51:35 +00:00

I think it's a great idea to start with a cli workflow before going on full-automation! Operator collaboration is much more complex than it looked like in the beginning.

Just some thoughts thought out loud. ..
It looks difficult to map the two models of server and app to one git repo.
Having sub-repo per app would be maybe the right mapping, but it feels overcomplicated and very difficult to use outside of abra.
Maybe pull is rather a server action? But it feels a bit wrong to not be able to pull an app directly, when all other versioning actions are per app.

From a cli / workflow perspective i'd prefer a abra app pull <domain>. Idk how likely it is to run here into conflicts if we'd just git pull here. But it could definitly be very misleading if suddenly conflicts from a different app .env appear.
From a design perspective I'd prefer abra server pull

I think it's a great idea to start with a cli workflow before going on full-automation! Operator collaboration is much more complex than it looked like in the beginning. Just some thoughts thought out loud. .. It looks difficult to map the two models of server and app to one git repo. Having sub-repo per app would be maybe the right mapping, but it feels overcomplicated and very difficult to use outside of abra. Maybe pull is rather a server action? But it feels a bit wrong to not be able to *pull* an app directly, when all other versioning actions are per app. From a cli / workflow perspective i'd prefer a `abra app pull <domain>`. Idk how likely it is to run here into conflicts if we'd just `git pull` here. But it could definitly be very misleading if suddenly conflicts from a different app .env appear. From a design perspective I'd prefer `abra server pull`

p4u1 commented

2024-12-30 14:03:32 +00:00

Two Git repo configs are supported.

"global" aka $ABRA_DIR/servers/.git
"server" aka $ABRA_DIR/servers/<server>/.git

Note that we at K & M are using $ABRA_DIR/.git. But maybe we could also switch to $ABRA_DIR/servers/.git. I would prefer it if it were flexible.

In general I'm not sure if it is too early to implement full operator sync in abra. I would be interested how different collectives handle this currently and where are the main pain

For us one pain point is, that people may forget to pull before deploying. A simple fix for that could be to check if there are remote commits, that are not local and then ask for

Maybe we could focus save abra + git usage before trying to automate this?

Will need to think about this some more, and I'm also interested what others think :)

> Two Git repo configs are supported. "global" aka $ABRA_DIR/servers/.git "server" aka $ABRA_DIR/servers/<server>/.git Note that we at K & M are using `$ABRA_DIR/.git`. But maybe we could also switch to `$ABRA_DIR/servers/.git`. I would prefer it if it were flexible. In general I'm not sure if it is too early to implement full operator sync in abra. I would be interested how different collectives handle this currently and where are the main pain For us one pain point is, that people may forget to pull before deploying. A simple fix for that could be to check if there are remote commits, that are not local and then ask for Maybe we could focus save abra + git usage before trying to automate this? Will need to think about this some more, and I'm also interested what others think :)

p4u1 commented

2024-12-30 14:08:11 +00:00

For git repo detection we could check if the .env file is inside a git repo

For git repo detection we could check if the `.env` file is inside a git repo

decentral1se commented

2024-12-30 14:27:56 +00:00

Amazing stuff folx, thanks for weighing in. From this and a quick chat on the Matrix tech channel, I think it is now clear to me that we "don't know what we're dealing with".

I will take time during the upcoming kite flying hour to write up some questions that I will send to you all (and publish to the network for more feedback). Then we can try once more to come back with a proposal / design which does meet concrete needs.

Also, it'll be fun to see everyones whacky workflows 😂 Feel free to keep bringing in feedback on this ticket, I'll read it!

Amazing stuff folx, thanks for weighing in. From this and a quick chat on the Matrix tech channel, I think it is now clear to me that we "don't know what we're dealing with". I will take time during the upcoming kite flying hour to write up some questions that I will send to you all (and publish to the network for more feedback). Then we can try once more to come back with a proposal / design which does meet concrete needs. Also, it'll be fun to see everyones whacky workflows 😂 Feel free to keep bringing in feedback on this ticket, I'll read it!

❤️ 1

decentral1se closed this pull request

2024-12-30 14:27:56 +00:00

decentral1se commented

2024-12-30 14:29:24 +00:00

Removing from the upcoming release planning for now. We do have toolshed/organising#661 in the meantime, which is a pretty significant leap forward.

Removing from the upcoming release planning for now. We do have https://git.coopcloud.tech/toolshed/organising/issues/661 in the meantime, which is a pretty significant leap forward.

decentral1se referenced this pull request from toolshed/organising

2025-08-29 10:27:32 +00:00

Operator collaboration #467

iexos referenced this pull request

2026-03-26 16:50:24 +00:00

Operator sync resurrected #809