Recovering the scripts / ad-hoc command interface #301
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#301
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Recovering the abra.sh scripts interfaceto Recovering the scripts / ad-hoc command interfaceOK, I've got 3 functions implemented in https://git.coopcloud.tech/coop-cloud/hometown/src/branch/main/abra.sh that I think cover what we need to support. A regular function that should be run in the context of a container with 0 args, one with args & a function that should be run on the local work station.
I'm trying to come up an API for this which builds on our discussions / previous attempts:
Where
--env
specifies the environment to run the bash function within (e.g.streaming
is a service. if not passed, defaults toapp
?). For functions that should only be run with--env local
, we can thread aCMD_ENV=$env
(or whatever) into the invocation so that the script can error out if is run in the wrong environment.For implementation: I think I can just copy the
abra.sh
over to/tmp
at run-time and run the script with args. Otherwise it is on the local work station which is easy.This will require some docs writing also.
I've tested the
-- <unlimited free args passed to function
in the following:And it seems to strip
--
correctly and thread the rest. Should work!@3wordchant @knoflook whatcha reckon?
great! I like it!
I first found the term
env
for this a bit misleading. If I understand it correctly, it chooses the service of an stack (app). I first thought of some extra .env file to load...maybe one of this is more self-explanatory?
abra app cmd social.foo.com migrate --service streaming
or
abra app cmd social.foo.com streaming migrate
is maybe even closer to theabra app run
syntaxBut I would also be fine with
--env
, was just a bit confused when reading it first.Oh yes, makes sense @yksflip! The
app run
syntax example looks solid. Maybe then for the scripts that should be run on the local work station, we can use--local
like we do forserver add
.so we're going with:
abra app cmd <app> <service> <command> [--local]
?if so, i think that's great!
Usage in the wild https://git.coopcloud.tech/coop-cloud/outline#deleting-a-user-e-g-to-fix-sso-weirdness
I am not sure if I should open an issue or just append to this closed one?
The --local flag behaves slightly different, than it should. As I understand it should be used like this
abra app command <domain> --local <command> -- <arguments>
but in this case the<command>
is interpreted as missing service. Instead I have to runabra app command <domain> --local -- <command> <arguments>
.Either the Usage description or the command interpretation should be fixed.
EDIT:
The behaviour changes if I use the --local flag before the domain. If I run
abra app command --local <domain> <command> <arguments>
(without--
) it is also working, but still not as stated in the USAGE.Nice @moritz, I've opened up #352 to track 👍