✨ Do not send `dagger version` to cloud

[levlaz]

What are you trying to do?

Right now when you call dagger version we send a trace to the cloud. This seems a bit silly and for larger teams contributes to the noise. We should supress these traces from being sent.

Why is this important to you?

Reducing signal vs noise in cloud is a good thing, this feels like a small but easy win.

--

Adding @jpadams suggestion for how this should work by default:
✅ = sends traces
❌ = does NOT send traces

DAGGER CLI                                                            TODAY            NEXT
  dagger        The core dagger command                                ✅               ❌ (--debug ✅)

DAGGER CLOUD COMMANDS
  login         Log in to Dagger Cloud                                 ❌               ❌ (--debug ✅)
  logout        Log out from Dagger Cloud                              ❌               ❌ (--debug ✅)

DAGGER MODULE COMMANDS
  call          Call a module function                                 ✅               ✅
  config        Get or set the configuration of a Dagger module        ✅               ❌ (--debug ✅)
  develop       Setup or update all the resources needed               ✅               ❌ (--debug ✅) 
                    to develop on a module locally
  functions     List available functions                               ✅               ❌ (--debug ✅) 
  init          Initialize a new Dagger module                         ✅               ❌ (--debug ✅)
  install       Add a new dependency to a Dagger module                ✅               ❌ (--debug ✅)

EXECUTION COMMANDS
  query         Send API queries to a dagger engine                    ❌               ❌
  run           Run a command in a Dagger session                      ✅               ✅

ADDITIONAL COMMANDS
  completion    Generate the autocompletion script for the             ✅               ❌ (--debug ✅)
                    specified shell
  help          Help about any command                                 ✅               ❌ (--debug ✅)
  version       Print dagger version                                   ✅               ❌ (--debug ✅)

[jpadams]

I'd suggest that most commands NOT send traces except dagger call, but you could force a send with -d or other flag which would be great for collaborative troubleshooting.
✅ = sends traces
❌ = does NOT send traces

DAGGER CLI                                                            TODAY            NEXT
  dagger        The core dagger command                                ✅               ❌ (-d)

DAGGER CLOUD COMMANDS
  login         Log in to Dagger Cloud                                 ❌               ❌(-d)
  logout        Log out from Dagger Cloud                              ❌               ❌(-d)

DAGGER MODULE COMMANDS
  call          Call a module function                                 ✅               ✅
  config        Get or set the configuration of a Dagger module        ✅               ❌ (-d)
  develop       Setup or update all the resources needed               ✅               ❌ (-d) 
                    to develop on a module locally
  functions     List available functions                               ✅               ❌ (-d) 
  init          Initialize a new Dagger module                         ✅               ❌ (-d)
  install       Add a new dependency to a Dagger module                ✅               ❌ (-d)

EXECUTION COMMANDS
  query         Send API queries to a dagger engine                    ❌               ❌
  run           Run a command in a Dagger session                      ✅               ✅

ADDITIONAL COMMANDS
  completion    Generate the autocompletion script for the             ✅               ❌ (-d)
                    specified shell
  help          Help about any command                                 ✅               ❌ (-d)
  version       Print dagger version                                   ✅               ❌ (-d)

[levlaz]

I'd suggest that most commands NOT send traces except `dagger call`, but you could force a send with `-d` or other flag which would be great for collaborative troubleshooting. ``` DAGGER CLOUD COMMANDS TODAY NEXT login Log in to Dagger Cloud ❌ ❌ logout Log out from Dagger Cloud ❌ ❌ DAGGER MODULE COMMANDS call Call a module function ✅ ✅ config Get or set the configuration of a Dagger module ✅ ❌ (-d) develop Setup or update all the resources needed ✅ ❌ (-d) to develop on a module locally functions List available functions ✅ ❌ (-d) init Initialize a new Dagger module ✅ ❌ (-d) install Add a new dependency to a Dagger module ✅ ❌ (-d) ```

This is a great suggestion, I agree. P.S. how did you make this awesome table? :)

[jpadams]

@levlaz the power of Vim! Fixed-width FTW!

[marcosnils]

@levlaz the power of Vim! Fixed-width FTW!

GFM also supports proper tables https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables

[levlaz]

@jpadams the only one I disagree with is

run - I think this should send traces, and I thought it actually did already?

[marcosnils]

@jpadams the only one I disagree with is

run - I think this should send traces, and I thought it actually did already?

yes, run currently sends traces to cloud, so we should keep it as-is

[jpadams]

@jpadams the only one I disagree with is
run - I think this should send traces, and I thought it actually did already?

yes, run currently sends traces to cloud, so we should keep it as-is

Oh, you're right, of course! 💯 agree!

Updated tables.

[vito]

With v0.12.1 the new rule is "we'll only send a trace to Cloud if the command actually had to interact with an engine."

There's no special --debug override though.

So now we have the following table:

DAGGER CLI                                                            CLOUD
  dagger        The core dagger command                                 ❌

DAGGER CLOUD COMMANDS
  login         Log in to Dagger Cloud                                  ❌
  logout        Log out from Dagger Cloud                               ❌

DAGGER MODULE COMMANDS
  call          Call a module function                                  ✅
  config        Get or set the configuration of a Dagger module         ✅
  develop       Setup or update all the resources needed                ✅
                to develop on a module locally
  functions     List available functions                                ✅
  init          Initialize a new Dagger module                          ✅
  install       Add a new dependency to a Dagger module                 ✅

EXECUTION COMMANDS
  query         Send API queries to a dagger engine                     ✅ (always has afaik)
  run           Run a command in a Dagger session                       ✅

ADDITIONAL COMMANDS
  completion    Generate the autocompletion script for the              ❌
                    specified shell
  help          Help about any command                                  ❌
  version       Print dagger version                                    ❌

This feels pretty reasonable to me, and satisfies the original request for this issue, but I'll leave it to y'all whether it should be closed or whether we should pursue the rest of the table.

[jpadams]

@vito I realized that there's the difference between traces/telemetry being sent and whether those traces are actually shown in Cloud. If they aren't sent, there's not the option to show/not-show in cloud. I think the intent was to actually make the feed less noisy, but the implementation we "asked for" was to send less, which may have been wrong-headed.

[jedevc]

IMO, regardless of what we decide about query/run/etc (I think a filter makes sense for these in cloud), version/help/completion/etc should never be sent to cloud.

Uploading a trace to cloud does have a latency cost, taking precious milliseconds to complete - with the changes to never upload dagger version traces, I notice the command returning instantly (tbf, running it as frequently as I do is probably rare).

I think we should distinguish between "doing commands" and "meta commands" here. A "do" command is one that has done a thing, and so should be send to cloud (maybe for later filtering). But a "meta" command is about the local configuration/etc of the CLI itself - it's going to be less useful for later querying, and increases the latency of those commands.