toolshed/abra
toolshed/abra
4
2
Fork 18
Code Issues 27 Pull Requests 3 Packages Releases 40 Activity

WIP: operator collaboration #457

Closed
decentral1se wants to merge 1 commits from opcollab1 into main
pull from: opcollab1
merge into: toolshed:main
Conversation 5 Commits 1 Files Changed 13 +319 -20
decentral1se commented 2024-12-29 19:59:38 +00:00
Owner
Copy Link

coop-cloud/organising#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
  2. "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
  2. 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
yksflip commented 2024-12-30 13:51:35 +00:00
Member
Copy Link

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
Member
Copy Link

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
Member
Copy Link

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
Author
Owner
Copy Link

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
Author
Owner
Copy Link

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.
All checks were successful
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/pr Build is passing
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something is not working
build
go build related issues
ci/cd
Building things with CI/CD
contributing
Dealing with contributing
critical fix
https://docs.coopcloud.tech/federation/resolutions/passed/010/
design
UI/UX
documentation
Documenting all the things
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
meta
relating to the project or repo itself
question
More information is needed
release
Release management
release-candidate
Related to the new release candidate
security
Security related
test
Unit/integration testing
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm carla cas decentral1se fauno kawaiipunk knoflook lambdabundesverband moritz p4u1 simon trav val yksflip
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#457
No description provided.
Delete Branch "opcollab1"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?