Just to reiterate the draftiness of all this: I think I'm going to move the get/create/replace logic into a new mutation on the backend, after sleeping on it. So, again, don't get too hung up on how this works just yet.

But, there's one thing that is ready for us all to talk about: what noun and verb do we use in the command structure? I've chosen remote and run, respectively. run matches the UI. remote is there because users won't really think of "server" or "SSBC" as concepts, but "remote" feels like a good description of what's going on.

Why do we need a noun and a verb? I think src batch run-remote -f foobar.yml is perfectly fine. Or remote-run. Or just src batch remote -f foobar.yml? I also can't think of any other commands that would be nested under remote (and that wouldn't work as other standalone commands)

An open question: should the existing commands move to a src batch local namespace, with everything aliased for now to make it work?

IMHO: No

Another open question: should there even be namespaces there? Malo's original concept in sourcegraph/sourcegraph#26503 used -remote or -executor, but I'm not convinced by this: I think it's going to be too easy for users to be confused about where their batch specs are being executed. I could be convinced, though.

I'd use a different command, not a flag.

Why do we need a noun and a verb? I think src batch run-remote -f foobar.yml is perfectly fine. Or remote-run. Or just src batch remote -f foobar.yml? I also can't think of any other commands that would be nested under remote (and that wouldn't work as other standalone commands)

I could see status commands being under src batch remote as well: something like src batch remote status <ID> feels plausible. That said, I'm struggling enough to think of a use case that we probably shouldn't decide based on that. 🙂 So I could be convinced on src batch remote -f foobar.yml, I think.

I don't love run-remote or remote-run — my concern here is that, conceptually, executing a batch change locally also implies that it's being "run". It feels like a weird special case that we only have this for remote.

@malomarrec, since you wrote the original issue here with a flag, what are your thoughts?

I could see status commands being under src batch remote as well: something like src batch remote status feels plausible. That said, I'm struggling enough to think of a use case that we probably shouldn't decide based on that. 🙂 So I could be convinced on src batch remote -f foobar.yml, I think.

I could see this being integrated in CI or another automation, and users using SSBC as part of a longer toolchain and scripting around it. That said, none of the options are incompatible with this, it's just that having src batch list-remote and src batch get-remote <id> etc etc sounds a bit heavy.

One reason I had in adding the remote flag as opposed to changing the command was that, in my mind, running locally or remotely are the same operation (with similar flags), so they should be expressed similarly (with a modifier). But that's a debatable UX opinion.

With that in mind, I actually like Adam's proposal:
src batch remote apply and src batch remote preview are very easy to grok since they map cleanly to the existing verbs

I'm also on board with the proposal for src batch remote apply and src batch remote preview. Beyond even just pinging the status in CI or something, it seems to me that working with remote machines comes with a whole new set of concerns that src never previously had to worry about when everything was just running locally, and I'd hate to imagine that one day we want 20+ remote-specific commands that all have to be named verb-remote.

I also would have voted for using the src batch local namespace for existing commands, though, so I'm curious to hear other opinions on this. My thought is that we've agreed that as a product we want SSBC to be the new default, and I would expect alignment on that between the web GUI and the CLI. If src batch apply executes locally and I have to use a separate namespace for SSBC commands, though, that's at odds with "SSBC is the default".

Personally, I'd love if users were able to configure which environment the alias src batch apply|preview would target, so that someone who always wants to execute them locally and someone who always wants to execute them on a remote executor could just set up the command alias for local|remote once and then forget it. For parity with the current version of src-cli, the default could be local, but in some future version when SSBC goes GA, this default could potentially switch to SSBC.

My question regarding src batch remote [apply|preview]: what would those do? Create the execution and then show progress until it's finished and then apply or preview the batch spec?

(I somehow assumed we're only talking about a command that "submits" a batch spec to Sourcegraph and prints a URL to watch the execution.)

I also would have voted for using the src batch local namespace for existing commands, though, so I'm curious to hear other opinions on this. My thought is that we've agreed that as a product we want SSBC to be the new default, and I would expect alignment on that between the web GUI and the CLI. If src batch apply executes locally and I have to use a separate namespace for SSBC commands, though, that's at odds with "SSBC is the default".

My thinking here is kinda: the CLI is a local tool (and not required for SSBC) so local execution should be the first-class citizen there and on Sourcegraph itself SSBC is the #1 thing, so it's the recommended way there.