#Liking the new summary output
1 messages ยท Page 1 of 1 (latest)
7 what reported? failures?
the inflated numbers are probably because it also counts internal vertices, so that counts things like sync() API calls that are made under the hood, which you don't normally see, only the failed vertices they result in
also before anyone says anything, that Duration: line is redundant, I have a fix for that in review ๐
I figured there were probably API calls causing the double counting. This is from the tests in our "better testing" talk, so lots of small, ephemeral layers, that have a .sync()
Cool, yeah not sure what to do about that. I suspect there are times where it helps to see that there's actually a lot going on, just that it's internal. And probably don't want to show some sort of split since that's likely info overload, and screen real estate is expensive
Maybe there could be a breakdown at the very last screen after everything finished, where real estate is cheaper
--stats
I have something like this in hof that shows the stages it ran, and the subtimes for various tasks
Having a consolidated report at the end would be nice, we produce these from our Jenkins workloads as a GIANT tree (lots of subjobs that need to be collected together)
We pull out results & times to build reports
nice, yeah that would be interesting
with Zenith those reports could theoretically include all of your individual test durations too
one thing CUE did was to have an ENV_VAR that holds a file name to write the stats out to
Since each test is a pipeline, I can see the timing of each today, and ideally I could get the tree/dag as a json-ish object?
One thing I noticed is that the depth of the colorful builds gets one more for each failure, but if they pass, the align nice as I scroll
It would be nice if they could stay vertically aligned
is this with the DAG TUI?
It's hard to guarantee much in terms of aesthetics, since what it's trying to render is already pretty difficult. I think I know what you're talking about though; it's because it "pulls" errored vertices towards the bottom so they're in view, but it also "pulls" running vertices towards the bottom for the same reason, which causes indenting because they come from different groups
oh yea, that pulling errors to the bottom, is that really needed? I'd personally prefer more stable output
So it might be possible to also tug them back over to the left, but that might also lead to stumbling onto an NP hard problem, not sure ๐
Personally, I like being able to just focus on the bottom of the screen for anything important. If errors get pushed into the scrollback I'm not likely to notice them
might be because of different use cases, I typically have failures as I'm developing
There's also an upcoming tweak to make the TUI truly non-interactive, which also means no longer being able to scroll around (anything offscreen will just be cropped), which would make that even more important. (The reason for this is so that the TUI won't steal input keystrokes from any interactive programs you run with it)
So let me know if that sounds terrible ๐
The original motivation for that is dagger shell
I noticed recently that I was now able to scroll, when before I couldn't, and did like that I could, because I can scroll back and look at an error while other things continue
One way I like to think about these things is to provide a flag to opt in/out of certain major behaviors (like taking over all keystrokes or not), let the user decide, becuase there are valid use-cases either way
yeah fair. I've been thinking to just re-enable it by default and disable it for certain commands that are incompatible (or a flag as you said)
another motivation was to get rid of the 'help' text, since it takes up a lot of room, and the only keystroke that does anything is 'q', which is just Ctrl+C
but I can probably just skip the help text anyway, not sure anyone ever used it; half of its content is only relevant to a currently disabled feature/easter-egg
I've tried it a few times, but it seemed to get me into some weird terminal input situation(s)
thanks for the feedback! generated a few TODOs ๐
I can add a flag/secret env var to disable the reordering behavior too, just to try it out
Adding another desired DX here, it would be great to be able to go into the failing tests to look around, run commands, etc...
I recall seeing a TUI just before this one that had navigation, where the details could be expanded on "focus"
It would be awesome to have a similar experience, but be able to drop into the failed / exited container afterwards
fyi: found a way to keep interactivity, without making it per-command. ๐ it's tricky, but seems reliable. you can even be viewing the DAG, scrolling around, open a shell, type into the shell, quit the shell, and go back to scrolling the DAG