add a warning if ~/.abra/servers/ has uncommitted git changes #267

New Issue

2021-11-24T21:34:09Z

3wordchant commented

2021-11-24 21:34:09 +00:00

Describe the problem to be solved

be me
disorganised, collaborating with a bunch of people, firing apps at the internet like it was a competitive sport
abra app config <something>
abra app config <something-else>
abra recipe create, hack on it some, and slam some uncommitted stuff into the live .env file because why not
...
time passes
...
collaborators try and edit app configuration, redeploy apps after inevitable SSO / custom theme / $general_docker_breakage
things break
I delete my hard drive in a not-rare flourish of chaos
deployed configs are lost to history

Describe the solution you would like

We already have ｉｎｃｒｅｄｉｂｌｙｒｏｂｕｓｔ checking of the git status of recipe repositories in ~/.abra/apps.

What about:

Check if the server directory, e.g. ~/.abra/servers/demo.coopcloud.tech/, is a symlink, and find the target if so.
If not, check if the entire abra servers directory ~/.abra/servers is a symlink, and find the target of that if so.
(Future-brain: if not, then maybe check if the entire ~/.abra directory is a symlink, and read ｔｈａｔ?)
Wherever we've decoded the symlink to, do a git status on that folder (possibly with git's default terrifying behaviour of traversing up the entire directory tree to see if any parent directories are git repoitories..?)
If there are any uncommitted changes in said repository, give us a friendly warning (pls not an error, I am optimistic about my ability to change but not delusional), e.g. `that shit = ain't commit``

During, I guess, any app-involving abra operation?

## Describe the problem to be solved > be me > disorganised, collaborating with a bunch of people, firing apps at the internet like it was a competitive sport > `abra app config <something>` > `abra app config <something-else>` > `abra recipe create`, hack on it some, and slam some uncommitted stuff into the live `.env` file because why not > ... > time passes > ... > collaborators try and edit app configuration, redeploy apps after inevitable SSO / custom theme / $general_docker_breakage > things break > I delete my hard drive in a not-rare flourish of chaos > deployed configs are lost to history ## Describe the solution you would like We already have ｉｎｃｒｅｄｉｂｌｙｒｏｂｕｓｔ checking of the git status of recipe repositories in `~/.abra/apps`. What about: 1. Check if the server directory, e.g. `~/.abra/servers/demo.coopcloud.tech/`, is a symlink, and find the target if so. 2. If not, check if the entire abra servers directory `~/.abra/servers` is a symlink, and find the target of _that_ if so. 3. (Future-brain: if not, then maybe check if the entire `~/.abra` directory is a symlink, and read _ｔｈａｔ_?) 4. Wherever we've decoded the symlink to, do a `git status` on that folder (possibly with git's default terrifying behaviour of traversing up the entire directory tree to see if any parent directories are git repoitories..?) 5. If there are any uncommitted changes in said repository, give us a friendly warning (pls not an error, I am optimistic about my ability to change but not delusional), e.g. `that shit = ain't commit`` During, I guess, any app-involving abra operation?

3wordchant added the enhancement abra labels 2021-11-24 21:34:09 +00:00

knoflook referenced this issue

2021-11-30 11:40:26 +00:00

easy config files synchronisation #271

yksflip referenced this issue

2023-07-19 16:32:47 +00:00

Operator collaboration #467

decentral1se referenced this issue

2023-07-19 22:26:40 +00:00

Operator collaboration #467

decentral1se commented

2023-10-05 21:43:36 +00:00

I think coop-cloud/organising#467 (comment) is maybe at odds with the approach proposed in this ticket. I think the warning would be a great feature if we can detect a git repository but #467 is proposing a much more automated approach. There could a dependency on finally doing coop-cloud/organising#303 to allow different modes of collaboration to happen?

I think https://git.coopcloud.tech/coop-cloud/organising/issues/467#issue-3577 is maybe at odds with the approach proposed in this ticket. I think the warning would be a great feature if we can detect a git repository but #467 is proposing a much more automated approach. There could a dependency on finally doing https://git.coopcloud.tech/coop-cloud/organising/issues/303 to allow different modes of collaboration to happen?

decentral1se referenced this issue

2023-10-05 21:44:03 +00:00

Operator collaboration #467

decentral1se referenced this issue

2023-10-09 19:50:41 +00:00

Collective maintenance often means hidden app upgrades #434

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#267