New Command: "launch"

[drewmalin]

Introduces a dedicated launch command that launches launchables, both remotely and locally. Remote execution essentially copies the existing brev create -l <id> flow (including some existing flags). Local execution:

• creates an OS-managed temporary workspace
• clones the launchable repository into that workspace when one is configured
• mounts the workspace for Docker and Docker Compose builds
• warns and asks for confirmation before running VM startup scripts directly on the host
• does not support verb mode

Demo:

brev.launch.mov

Helptext:

brev launch -h
Launch a launchable on its recommended remote Brev instance, or use --local to run its build on this machine. Local mode supports VM startup scripts, custom containers, and Docker Compose builds.

Usage:
  brev launch <launchable-id>

Examples:
  # Provision the launchable on a remote Brev instance
  brev launch env-abc

  # Inspect its definition without launching
  brev launch env-abc --explain

  # Launch on this machine
  brev launch env-abc --local

  # Supply direct parameter values
  brev launch env-abc --param MODEL=llama --param PORT=8080

  # Bind a text parameter to the latest or a specific managed-secret version
  brev launch env-abc --param-secret API_TOKEN=msec-abc
  brev launch env-abc --param-secret API_TOKEN=msec-abc:msecv-123

Flags:
      --approve                    Run a local startup script without prompting
  -d, --detached                   Do not wait for the remote instance or local Docker workload
      --explain                    Show launchable details without launching
      --local                      Run on this machine without provisioning an instance
  -n, --name string                Instance, container, or Compose project name
      --param stringArray          Launchable parameter NAME=VALUE (repeatable)
      --param-secret stringArray   Text parameter NAME=SECRET_ID[:VERSION_ID] (repeatable)
      --timeout int                Remote instance readiness timeout in seconds (default 300)
  -t, --type string                Comma-separated remote instance types to try

Global Flags:
  -h, --help              Help for Brev
      --no-check-latest   Do not check for the latest version when printing version
      --user string       Non root user to use for per user configuration of commands run as root
      --version           Print version output

[theFong]

Neat, so vm mode runs a script, container mode runs a container, and compose runs your compose.

Do we require the node to be connected/registered first so secure links work?

Do we have any intention of supporting cleanup/teardown?

[drewmalin]

Neat, so vm mode runs a script, container mode runs a container, and compose runs your compose.

Do we require the node to be connected/registered first so secure links work?

Do we have any intention of supporting cleanup/teardown?

My thought here was that we could support two levels of connectivity back to Brev:

1. This is truly just "local" (you haven't connected this compute to Brev at all) in which case this PR basically does the full job.
2. This is an external node, in which case we can do some tie-ins to the Brev side: logs could be submitted and viewed from the console for this node, and as you say, we certainly could support secure link creation.

The only "teardown" that exists is the fact that we use a temporary directory for git / mounting, and by default you are in the docker or vm script process, so hitting ctrl^c will kill the process. You can run the launch with --detached, but at that point the CLI is no longer aware of the process.

[patelspratik]

could we port this over to the remote launch also, we don't apply verb stuff there either. We should either reject or uptake Verb there (applyLaunchableBuildRequest)

[patelspratik]

for notebooks this will just be "url": "https://github.com/brevdev/notebooks/raw/main/oobabooga.ipynb". I think you might have to do some parsing like https://github.com/brevdev/dev-plane/blob/main/internal/remotefile/client.go does