Recovering the scripts / ad-hoc command interface #301

New Issue

OK, 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:

abra app cmd social.foo.com migrate --env streaming
abra app cmd social.foo.com admin -- d1 me@example.com
abra app cmd social.foo.com secrets --env local

Where --env specifies the environment to run the bash function within (e.g. streaming is a service. if not passed, defaults to app?). For functions that should only be run with --env local, we can thread a CMD_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:

package main

import (
	"fmt"
	"os"

	"github.com/urfave/cli"
)

func main() {
	action := func(ctx *cli.Context) error {
		fmt.Printf("input: %s", ctx.Args())
		return nil
	}

	x := cli.Command{Name: "x", Action: action}
	app := &cli.App{Commands: cli.Commands{x}}

	if err := app.Run(os.Args); err != nil {
		panic(err)
	}
}

And it seems to strip -- correctly and thread the rest. Should work!

➜ ./foo x -- a d f f 
input: [a d f f]%

@3wordchant @knoflook whatcha reckon?

OK, 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: ``` abra app cmd social.foo.com migrate --env streaming abra app cmd social.foo.com admin -- d1 me@example.com abra app cmd social.foo.com secrets --env local ``` Where `--env` specifies the environment to run the bash function within (e.g. `streaming` is a service. if not passed, defaults to `app`?). For functions that should only be run with `--env local`, we can thread a `CMD_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: ```go package main import ( "fmt" "os" "github.com/urfave/cli" ) func main() { action := func(ctx *cli.Context) error { fmt.Printf("input: %s", ctx.Args()) return nil } x := cli.Command{Name: "x", Action: action} app := &cli.App{Commands: cli.Commands{x}} if err := app.Run(os.Args); err != nil { panic(err) } } ``` And it seems to strip `--` correctly and thread the rest. Should work! ```bash ➜ ./foo x -- a d f f input: [a d f f]% ``` @3wordchant @knoflook whatcha reckon?

decentral1se referenced this issue from coop-cloud/hometown

2022-03-14 09:06:32 +00:00

Fix abra.sh commands #8

yksflip commented

2022-03-14 18:04:21 +00:00

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 the abra app run syntax

But I would also be fine with --env, was just a bit confused when reading it first.

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 the `abra app run` syntax But I would also be fine with `--env`, was just a bit confused when reading it first.

👍 1

decentral1se commented

2022-03-15 08:43:22 +00:00

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 for server add.

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 for `server add`.

knoflook commented

2022-03-17 12:11:50 +00:00

so we're going with: abra app cmd <app> <service> <command> [--local]?

if so, i think that's great!

so we're going with: `abra app cmd <app> <service> <command> [--local]`? if so, i think that's great!

👍 1

decentral1se referenced this issue from a commit

2022-03-27 15:12:01 +00:00

feat: bring back scripts interface

decentral1se referenced this issue from a commit

2022-03-27 15:20:27 +00:00

feat: bring back scripts interface

decentral1se referenced this issue from a commit

2022-03-27 15:30:24 +00:00

feat: bring back scripts interface

decentral1se referenced this issue from a commit

2022-03-27 19:31:00 +00:00

feat: bring back scripts interface

decentral1se closed this issue

2022-03-27 19:31:35 +00:00

decentral1se commented

2022-03-30 14:39:00 +00:00

Usage in the wild https://git.coopcloud.tech/coop-cloud/outline#deleting-a-user-e-g-to-fix-sso-weirdness

moritz commented

2022-10-25 11:27:41 +00:00

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 run abra 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.

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 run `abra 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.

moritz referenced this issue

2022-10-25 17:52:46 +00:00

env variables for local command in abra.sh #351

decentral1se referenced this issue

2022-10-27 08:43:45 +00:00

Confusing --local command syntax #352

decentral1se commented

2022-10-27 08:44:04 +00:00

Nice @moritz, I've opened up coop-cloud/organising#352 to track 👍

Nice @moritz, I've opened up https://git.coopcloud.tech/coop-cloud/organising/issues/352 to track 👍

moritz referenced this issue

2023-04-12 14:25:24 +00:00