dagger
✨ Do not send `dagger version` to cloud
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 ✅)
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)
I'd suggest that most commands NOT send traces except
dagger call, but you could force a send with-dor 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? :)
@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
@jpadams the only one I disagree with is
run - I think this should send traces, and I thought it actually did already?
@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 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.
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.
@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.
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.
