✨ AllowToFail in ContainerWithExecOpts ·...

[dense python]

just replied in GH

[opaque grotto]

A follow-up question: in Docker build when a command fails the container instance just goes away and there isn’t an easy way to inspect it after the exit code is non-zero, is this possible with to inspect the container fs of a failed command in Dagger?

[dense python]

not currently in a friendly way where you can just start a shell in the failed step. Here's the issue for that https://github.com/dagger/dagger/issues/4463.

You can export the fs to your local machine using the Export call if a step fails, but the plan is to allow anyone to drop a shell at any point of the pipeline for debugging purposes

we have some experiments with that (https://github.com/dagger/dagger/blob/main/cmd/dagger/shell.go) but the UX hasn't been fully defiend yet

[opaque grotto]

Won’t exporting the FS give the state before the command that failed ran? (At least that is what docker build does)

[dense python]

hmm that's right.. missed that 🤔

[eternal hatch]

@dense python Thanks for your answer. I think that is exactly what I need. But I'm still a bit confused about the documentation.
What is exactly the difference between "Handle exit code and unexpected errors" and "Continue using container after command execution fails"?
Is the later just to cache an execution even if the command return a non exit return code?

And by the way. Thumbs up for the whole Dagger team. For every question (even the dumb ones) I get a fast and proper response from you. I like and appreciate your community work! 🙂

[dense python]

"Continue using container after command execution fails"?

in the snippet that I've shared above, if you have some other steps in the chain after that exit 20 they won't be executed since the code will return an error when it reaches to that step. Some users would like to override that behavior and let the pipeline continue even though the command they executed returns something different than 0