#--with

1 messages · Page 1 of 1 (latest)

wispy shore
#

You supply a bit of CUE code that will be unified in with your plan. For example:

// usage: dagger do hello --log-format=plain --no-cache
package helloworld

import (
  "dagger.io/dagger"
  "dagger.io/dagger/core"
)

_alpine: core.#Pull & {
  source: "alpine:3"
}

dagger.#Plan & {
  actions: {
    hello: {
      greeting: string | *"hello"
      _exec:    core.#Exec & {
        input: _alpine.output
        args: ["echo", "\(greeting), world!"]
      }
    }
  }

}
#
helloworld ➤ dagger do hello --log-format=plain --no-cache            git:main*
1:39PM INF _alpine | computing
1:39PM INF _alpine | completed    duration=600ms
1:39PM INF actions.hello._exec | computing
1:39PM INF actions.hello._exec | completed    duration=100ms
1:39PM INF actions.hello._exec | #3 0.054 hello, world!
#

Now to supply a new greeting to the hello action, I can use:

dagger do hello --with 'actions:hello:greeting: "Hiya"'
#

Putting it all together:

helloworld ➤ dagger do hello --with 'actions:hello:greeting: "Hiya"' --log-format plain --no-cache
1:41PM INF _alpine | computing
1:41PM INF _alpine | completed    duration=900ms
1:41PM INF actions.hello._exec | computing
1:41PM INF actions.hello._exec | completed    duration=200ms
1:41PM INF actions.hello._exec | #3 0.134 Hiya, world!
#

An alternative way to do this is by filling in the greeting stringthis way.

You can ask what actions are available with --help:

helloworld ➤ dagger do --help                                         git:main*
Usage:
  dagger do  [flags]

Options


Available Actions:
 hello

and then take a closer look at how to use the hello action:

helloworld ➤ dagger do hello --help                                   git:main*
Usage:
  dagger do hello [flags]

Options
      --greeting string

Then use the --greeting flag available with the hello action:

helloworld ➤ dagger do hello --greeting "hello there" --log-format=plain --no-cache
Changed: greeting: hello there
1:46PM INF _alpine | computing
1:46PM INF _alpine | completed    duration=1s
1:46PM INF actions.hello._exec | computing
1:46PM INF actions.hello._exec | #3 0.054 hello there, world!
1:46PM INF actions.hello._exec | completed    duration=100ms

Would be good to hear from @azure steppe which way is going to be preferred going forward. Might not be decided yet 🙂

azure steppe
#

I think passing action inputs as flags should be the preferred way.

—with is a power user tool for debugging, hacking etc

#

you shouldn’t need —with in your day to day workflow

wispy shore
#

@marsh mica ☝️

#

@marsh mica I think in this case with a single string input, I see where the --flag makes a ton of sense. In the case where we ran a pre-processing script to get the data into shape, I can see where our --with approach made sense. I can also see that pre-processing the data into a JSON string, sending it in via a -- flag, and using json.Unmarshal might have been better than using the comma-separated list and the for loop. Though could have used https://pkg.go.dev/cuelang.org/go@v0.4.3/pkg/encoding/csv csv.Decode() on that list. Several ways to make it all happen 🙂

marsh mica
# wispy shore <@336241811179962368> I think in this case with a single `string` input, I see w...

it's always recommended to use flag arguments to dynamically send input values to actions. The case where we used the --with approach should be considered as an exception as we were "hacking" around a feature that it hasn't been yet properly crafted (dynamic tasks) since we're hitting some cueflow limitations to do that.
So yes, the general rule should be to use the --flag feature as much as possible with the exception of some cases as the one we had in the past

wispy shore
ornate widget
#

sorry I just noticed this thread now. Yeh, I actually prefer the --greeting format.

wispy shore