#TUI collapsable progress not working in gitlab terminal

1 messages · Page 1 of 1 (latest)

ancient hinge
#

Hello Folks 🙂
I am using dagger 0.11.9 and using dagger cli to run pipelines with TUI. TUI works well with collasable and scrollable in my local macbook but when i run same pipeline in gitlab job those logs are auto collapsable and ended up with printing everything on console.
Could you please help how to fix? Appreaciate quick help here 🙏

somber canyon
#

Heya 👋 so the TUI view can't be run in a collapsable way in gitlab/github/etc:
1 - there's no real way to get user input in those contexts, and it's super dependent on that
2 - the tui uses a lot of fun interactive features that just aren't available in a terminal like that
so for those views, we fallback to the plain progress

ancient hinge
#

hmm..so recommened usecase for TUI is local machine mostly right? 🙂

somber canyon
#

Yup exactly

ancient hinge
#

i have been discussing this in other threads. Running dagger run go main.go gives us certains benefits like application logs can also be part of otel by default, but i wish if we can disable logs by extending --silent but still send logs telemetry, may something like this --soft_silent feature

so in our usecase we don't require TUI feature but we do require telemtry logs from it 😄

lofty mason
#

@somber canyon this reminds me of our discussion on tuesday: TUI and telemetry are two different features, they may be tightly coupled in their implementation, but users expect them to be decoupled

somber canyon
#

i'm a bit confused sorry

lofty mason
#
  • Sometimes you want to see a TUI but not send telemetry
  • Sometimes you want to send telemetry but disable TUI
somber canyon
#

we always send telemetry for call/etc, no matter what flags we pass

#

i think if you're logged in, you should always be sending telemetry for commands that it makes sense to

lofty mason
#

(And my own request is: when we disable TUI for certain commands, can we not also disable sending telemetry)

somber canyon
#

cc @untold crown on that one, i don't really have strong opinions, but if we send telemetry, it needs cloud side changes

#

(to not show them in the list)

#

also @tepid pelican i guess

tepid pelican
#

so we would be sending telemetry without displaying it in the UI?

untold crown
#

Yeah, telemetry should be sent no matter what, the TUI is decoupled from that

somber canyon
#

will take a look at that

untold crown
somber canyon
#

ah

#

no there's an issue with this

#

cmd.OutOrStdout or whatever

#

we set that to the otel span

#

we need a frontend to print it 😱

#

otherwise, no output for you (or if always print to actual stdout, no output in cloud)

#

i guess we want a "dummy frontend"? or something like that

#

hm that feels like such a codesmell

untold crown
somber canyon
#

ahhh, is that cause the top-level span is the command itself?

untold crown
#

yeah

#

oh, dagger run just does something weird

#

we probably don't want that anymore notsureif

#

the frontend already painstakingly preserves the original stdout/stderr streams even when it's directed to otel, so it should be redundant

#

i think the OG intent was so people could pipe stdout/stderr independently and have them behave as expected

#

but that should work as-is with how the frontend works

#

so i think this can just unconditionally assign Stdout = cmd.OutOrStdout() (and stderr)

#

the only catch really is that it won't be a live stream - we'll buffer up stdout/stderr and print them on exit

somber canyon
#

🤔 hm

#

that might be an issue for users of dagger run

#

bleh, i'm kinda of on a different track, trying to understand how to get telemetry enabled for every command, but only show the frontend for some commands

#

cause the frontend is absolutely builtin to our understanding of how to display all otel output

#

but if the frontend is doing this, then we have to change frontend depending on command? but the frontend is determined at the beginning of main, so we'd need to push that further down

#

and so it's just kind of everything that needs refactoring

untold crown
#

a bit confused - what issue are you hunting down now? seems like the only problem is in dagger run?

#

the commands that don't use the frontend just use cmd.OutOrStdout() etc

somber canyon
#

and then use cloud to filter these out

lofty mason
#

That would be my preference yeah.

untold crown
#

oh. we had separate requests to not send telemetry for version / login / etc. though. overruled? 🧑‍⚖️

#

iirc some folks run dagger version as a quick sanity check in CI, and the extra noise in Cloud was annoying

somber canyon
#

even if we filter it in cloud, the issue is that dagger version isn't neccessarily expected to be networked

#

having removed the telemetry init from it, it's much faster

untold crown
#

also that yea, it's a super primitive command

ancient hinge
#

I am not using dagger cloud but my original ask is to control TUI logs and sending OTEL independantly as of now it is coupled with one flag --silent, we could have two flags to control both aspects eg: --soft-silent could just disable TUI but will send otel data no matter, but may be using --hard-silent we just disable both, just an opinion

ancient hinge
mint talon
untold crown
#

Yeah. You could probably run with plain progress and just direct stdout/stderr to a file or /dev/null as a workaround

ancient hinge
#

Actually this also will not solve my problem, because there are some info logs(from code itself)that we print out on stdout which is important logs for customers. Doing above solution also disable my application logs in console
So I have to wait eventually for this bug to be fixed before i even use dagger run
let me know when this issue will be solved in coming releases 🙂

ancient hinge
#

Any chance this fix/feature might be shipped in next release or so?