allow passing in the cli args to the components as env args

[karthik2804]

This PR enables passing in the CLI args passed to the component with the component ID used as the command name. eg:

Rust code

#[allow(warnings)]
mod bindings;

fn main() {
    let args = std::env::args();
    for arg in args {
        println!("{arg}")
    }
}

$ spin up these are some args
pin up this is something                     
Logging component stdio to ".spin/logs/"
sample # this is the component id
these
are
some
args 

The updated behavior is describe in #4 (comment)

[itowlson]

I wonder if having an unconstrained set of guest data directly in the spin up command is wise. In the case of trigger flags such as --listen it's okay because the trigger author can choose those to not clash with up or the trigger base etc. But guests, particularly if there is lift-and-shift going on, may make choices that clash. For example, a guest built using clap would get a --help flag, but a user could never invoke it because spin up swallows that flag. That's a fairly harmless example but hopefully makes sense.

I wonder if we should use a -- or something separator to delineate the Spin/trigger flags from the CLI args, e.g. spin up --log-dir foo -- --guest flags --here. Not sure of the implications or practicalities - just flagging for thought.

[fibonacci1729]

Thats a good point. IIRC to do this you can #[arg(trailing_var_arg = true, allow_hyphen_values = true] or maybe its #[arg(last = true)].

[karthik2804]

I was playing around with it and setting #[clap(parse(from_str), last(true))], makes the incantation

spin up -- -- test

notice the double--. This may possibly be due to https://github.com/fermyon/spin/blob/e198b9ffa716336b1d1a3983b7d463047f09e553/src/commands/up.rs#L118

[radu-matei]

Good point, @itowlson.

In fact, there is another place where we need to make sure we can reliably pass arguments: the shim.

spinkube/containerd-shim-spin#50 (comment)

For example:

spec:
  initCcontainers:
  - name: spin-init
    image: ttl.sh/spinkube-init:24h
    command: ["/"] # most likely keep this as "/"
    args: ["these", "are", "some", "args"]

[karthik2804]

With the latest changes from @fibonacci1729, the behavior is that anything passed after the -- is passed to transparently to the guest.

$ spin up -f example -- one two three -h
CliArgs { id: None, guest_args: ["one", "two", "three", "-h"] }
simple # component_id
one
two
three
-h

(the debug print of CliArgs is just used to show how things are parsed when the trigger has its own args)

[karthik2804]

@radu-matei I am not sure about how to test the usage in the shim.

[radu-matei]

This app manifest works in the shim using the command trigger from this branch:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spin-test-init
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spin-test
  template:
    metadata:
      labels:
        app: spin-test
    spec:
      runtimeClassName: wasmtime-spin-v2
      initContainers:
      - name: spin-init
        image: ttl.sh/spinkube-init-args:24h
        args: ["these", "are", "some", "args"]
      containers:
      - name: spin-test
        image: ghcr.io/deislabs/containerd-wasm-shims/examples/spin-rust-hello:v0.10.0
        command: ["/"]
        ports:
        - containerPort: 80

Getting the logs from the init container:

$ kubectl logs pods/spin-test-init-5f4d994596-q8wfh -c spin-init
hiwasi
these
are
some
args

The "command" being injected as the component name makes sense to me.