#Geoff experiments
1 messages · Page 1 of 1 (latest)
Starting a thread to spare #1113696290577059851 from the volume
And catching up to understand your idea
@modern inlet is the issue that you’re not seeing the stderr of an exec when it’s cached? Or something else?
Not seeing cached stderr
And by “seeing” you mean retrieving its value via the API? Or looking for it in the engine logs in the terminal?
I think from my perspective as a new user, I was expecting the builds to be both deterministic in execution and in introspection. As a consumer of the node SDK, I thought that the way I observed the outcome of a build would be identical across runs if no changes were made. The presence of a cached build changing the introspection output is surprising.
My first impression was that it was broken; not that it was expected behaviour.
Feels like something that could be clarified through docs or somehow cached and keyed on the layer hashs or something.
I think that maybe the samples and design of the api leads a (new) user to believe that .stdout() and .stderr() would always return output. I think I can see why it might not if I imagine how things are using buildkit.
if we’re talking about retrieving the value of stderr , then yes you are correct. It should always be available whether cached or not
otherwise it’s a bug
however that doesn’t apply to displaying in the logs
(which is why I asked)
Gotcha, I wasn't expecting it to be piped to stdout / stderr on a warm cache.
Very clever API design btw. 😄
Also shipping the engine in the npm module makes those first steps so nice and frictionless.
Are you 100% sure that was the actual behavior? Could it be something else that you experienced?
I shared the verbatim code and logs from the terminal in the gist.
Can put together a proper ticket tomorrow.
The gist sorted the files in a hard-to-parse way. I've updated it with logical ordering: https://gist.github.com/ggoodman/e0f5b905e99d8ffefb0d84a8f59d15f9
Oh wait.
This might well be a solid PEBCAK
You can try wrapping your script execution with dagger run to see improved interactive output
might help troubleshoot
No this is 💯 a user-error.
The error is of the dumb variety where, to my surprise, my test runner outputs on stdout while I was just attempting to log stderr.
Curious how that will work out ultimately! Anyway, sorry for this false alarm.
No worries at all
I’m glad you’re unblocked
I still recommend trying dagger run node run …
(we should really update the docs to make that the default)
I didn't see it mentioned in the tutorial how y'all recommend to install dagger so I just tried the node-driven workflow. Just pulled in the binary view homebrew and 🤯 on the cool 'subway diagrams' or whatever they're called. WOW!
Ha ha you mean via dagger run ? 🙂
Yeah!