easy/best way to capture with_exec exit codes?

[little hawk]

Is the only way to capture the shell output as a file and parse? Seems like that is a bit messy. Does the with_exec function have the option to return the exit code?

Using Python and dagger 0.12.2

[earnest tendon]

👋 you can currently get the code if the exec fails by casting the error as a dagger.ExecError https://dagger-io.readthedocs.io/en/sdk-python-v0.12.3/exceptions.html#dagger.ExecError.

The shell output capture is only in the case that you need to ignore the error and continue executing the pipeline

[little hawk]

🖐️ that did it! I was looking at the wrong exception

Is there some reason why I couldn’t use contextlib.suppress to continue execution of the pipeline?

[earnest tendon]

cc @spare reef would know better as he's our guru

[little hawk]

Yeah, nothing major as I just saw this today but seems to fit nicely. But before I went hog wild, wanted to make sure I wasn’t missing anything 😄

[spare reef]

Not really, assuming you don't continue on with the same thing that originated the error in the first place. If it didn't work for you I can take a look.

As for your original question, you don't need to capture the shell output yourself since you can use with_exec([...], redirect_stdout=<file>).

[little hawk]

Yeah I’m seeing the downside is that I lose the ability to store the results of a command in a variable. So maybe not the best for my use case of unit tests

[spare reef]

Yep 🙂

[little hawk]

Ah well, might come useful down the road, thanks both!

[little hawk]

Okay so maybe I’m overthinking this but even with the stdout file, the exec function is returning a nonzero exit code and it’s halting. Do I need to spawn a new shell and then capture that?

Pytest throws back a 1 if some tests failed, and it’s not a reason to fail the whole thing

[spare reef]

Yeah, you still need to capture the exit code, like in Cookbook: Continue using a container after command execution fails, just don't have to also redirect the output via the shell too, with that option.

[little hawk]

Would it be feasible to make that a return value in the function? I can’t imagine that it’s an uncomment requirement, and spawning new shells seems a bit hacky. Especially downstream where we might have virtual envs, or other shell specific requirements

[spare reef]

Return value in the function? Can you clarify?

[little hawk]

So basically in my code I have this:

ctr.with_exec([“sh”, “-c”, “python -m pytest…”], redirect_stdout=“pytest-out”)

because I have some failing unit tests, pytest outputs and exit code of 1 and the dagger cli returns an error. If I suppress the error I can continue but my container doesn’t persist since it errored out so I can’t actually do anything to validate the output is created or with the output in the container.

I can post more later, Discord is blocked on my work computer and I’m using my mobile to type…not efficient

[earnest tendon]

If I suppress the error I can continue but my container doesn’t persist since it errored out so I can’t actually do anything to validate the output is created or with the output in the container**.

What do you mean by suppressing the error? Doing this https://docs.dagger.io/cookbook/#continue-using-a-container-after-command-execution-fails ?

^ if you're doing that, since the error is "suppressed", you can continue using the container normally and also access the stdout/err as needed

[little hawk]

either in a try except, or a while block using contextlib.supressped. Both catch the error from the container and go right to the except block.