#error handling

1 messages · Page 1 of 1 (latest)

dire juniper
#

I noticed that dagger.Container Stdout() method returns an error string that contains stderr and stdout, if the last WithExec command fails.
(defined here: https://github.com/dagger/dagger/blob/6dac0951b62d85b48316c1194b468898b11c2199/core/gateway.go#L201)

I would like to apply custom logic in that case:

  • Print the actual command stdout to stdout
  • Print stderr to stderr
  • Exit if exitCode != 1.

The motivation is to use dagger as vim makeprg for quickfix errors. (https://vimdoc.sourceforge.net/htmldoc/quickfix.html)
I need a clean stdout for that...

Is there a way (other than parsing the error string) to achieve that?

GitHub
dagger/gateway.go at 6dac0951b62d85b48316c1194b468898b11c2199 · dag...

A programmable CI/CD engine that runs your pipelines in containers - dagger/gateway.go at 6dac0951b62d85b48316c1194b468898b11c2199 · dagger/dagger

slow breach
#

In case of error, you're only option right now is to parse the error message with a regex for example. I'm trying to look for a solution, the main question is, do we fix these fields breaking a lot of users that have come to depend on how things work now, or do we simply create new ones to make a deprecation path?

dire juniper
#

Thanks @slow breach . Yeah, I just saw that 🙂

I don't know if it's related, but the stdout inside the error message is trimmed sometimes.
I'd be happy to open a separate issue if it's not.

slow breach
#

Yes, I there may be an issue on that already. I've seen it mentioned multiple times, but haven't reproduced it.

#

If you can look for an open issue and create a new one if not, while adding a reproducible example, that would be very helpful.

dire juniper
#

These issues block me from replacing a Makefile with Dagger for local development purposes.
Would it be helpful to jump on a call and try to reproduce it?

dire juniper
slow breach
#

Can you clarify what specifically is blocking you? Apart from truncated stdout.

dire juniper
#

The truncated output - I'm missing errors from GolangCI-lint, so I must run Dagger multiple times for lint purposes.
Error handling/stdout/stderr - Not a blocker because I can parse the error message using regex (for now). Needed for VIM and quickfix integration.

slow breach
#

Not familiar with that integration, how does that work?

dire juniper
#

VIM is running dagger binary and parses its stdout. If the output contains errors it shows them in a list of errors, so the developer can fix them one by one.

slow breach
#

Curious to see that in practice 🙂 Is there something I can read?

dire juniper
slow breach
dire juniper
slow breach
#

Is the dagger pipeline you're using there public?

dire juniper
#

not yet

slow breach
#

Can you ping me when it's available?

dire juniper
#

We're developing it mostly for internal usage (build system for our platform).
We might consider open it to the public since it's mostly generic buildsystem for go+grpc.

I still need to think about that

dire juniper
slow breach
dire juniper
#

I think it would be ideal to get an io.Reader interface for stdout, stderr, and a combined one

#

I would probably just wrap the messages with an io.Reader to make it work with native functions

#

I don't know if Graphql/BuildKit supports streaming information in this fashion

slow breach
#

No, you'd only get the full stdout/stderr each time you request it. So if you're running multiple commands in the pipeline it feels like you're streaming command by command, rather than line by line.

#

Have you tried #general message ? It can be used as a debug tool, which makes needing stdout/stderr in the pipeline not necessary in many cases. I know you still need them for VIM + quickfix, I'm actually interested in the use cases where using that TUI doesn't replace getting the stdout/stderr.

dire juniper
#

I haven't tried it yet. It looks promising for debugging (I'm a big fan of TUI 🙂 )
In my perspective, it helps debug the build system itself.

I'm looking for a way to ship our engineers a simple tool that builds binaries and always cleanly prints command errors - just like running a Makefile command (make build, make lint will become dagger-make build dagger-make lint).
(or from dagger readme: A platform engineer writing custom tooling, with the goal of unifying continuous delivery across organizational silos Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful)

so printing command input and output in non-tui mode is important

slow breach
#

With the entrypoints, you'd run pipelines like dagger do lint, no matter which SDK it's implemented in.

dire juniper
#

Right now we're building a custom binary entrypoint. which is good enough for me

slow breach
#

Yes. Do you think having these entrypoints would simplify your use case, or would you rather just do what you're doing?

dire juniper
#

Hmm not sure; it depends on the end result.
I liked how easy and flexible it was to write my cli using cobra+dagger and containers (such as golangci-lint)

slow breach
#

Got it 🙂 Thanks for the chat. I'm looking into the issues around the error handling that you're affected by. I'm just not familiar with the stdout truncation. Some weeks ago a user complained about that but I couldn't reproduce it. If you can make a simple example to reproduce that issue that would be helpful.

#

Please take into consideration if the stdout is the last thing in the pipeline because the engine could be shutting down before getting everything. The Go SDK has a timeout for that to try to prevent it, but there could be something there still. So it's especially useful to replicate when it's not the last query.

dire juniper
#

I don't think that's what happened in my case.
I'm missing a prefix:

Stdout:
consider removing or renaming it as _ (revive)
    toDelete *Action,
    ^
internal/page.go:120:60: unused-parameter: parameter 'pageSize' seems to be unused, consider removing or renaming it as _ (revive)
func (s *action) Get(ctx context.Context, pageSize int) ([]byte, error) {
                                          ^

The first line is trimmed

slow breach
#

Hmm... it's not always trimmed so I wonder what's causing that. Are you using services?

#

Does it always get trimmed with your pipeline?

dire juniper
#

I'm using services, but not in this pipeline. It always gets trimmed.

I'm checking if it's related to colored-line-number

slow breach
#

Ah, haven't thought of special codes.

dire juniper
#

I switched to line-number and it still happens

#

I'll try to open a ticket with how to reproduce it. probably not today tough 😦

slow breach
#

That would be awesome 🙂 Whenever you can, thanks.

dire juniper
#

Thanks for your assistance @slow breach

slow breach
#

Just to be clear, is the golangci-lint command the one where your output's trimmed?