You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the docs: "Final tasks are guaranteed to be executed in parallel after all PipelineTasks under tasks have completed regardless of success or error."
Actual Behavior
If a final task references the result of a task which exited with an error, that final task is skipped.
Steps to Reproduce the Problem
Run a pipeline with:
A failing task
A final task that depends on a result from the above
% tkn pr describe test-finally-xxxxx
Tasks Completed: 1 (Failed: 1, Cancelled 0), Skipped: 1 ("step-fail" exited with code 1 (image: "docker-pullable://alpine@sha256:234cb88d3020898631af0ccbbcca9a66ae7306ecd30c9720690858c1b007d2a0")
...
Skipped Tasks
NAME
∙ final
Removing the final task's input param and using the default value instead makes the final task run as expected.
Writing something to $(results.missing.path) before exiting with an error does not change the behavior; a non-zero exit code seems to be sufficient to trigger this.
hey @joshfrench, when a task exits with an error, the results are not added to the status. The results are only initialized with a successful task. @afrittoli has requested a result (or something similar) to be made available even when a task fails with error, see issue #3749.
Also, if you have a use case where you would like to continue after a step error and also have the result initialized before exiting with 1, we have a proposal to introduce a feature to ignore step error https://github.com/tektoncd/community/blob/main/teps/0040-ignore-step-errors.md. The implementation PR is open as well. You can refer to the example demonstrating the results with the failed steps here.
Thanks @pritidesai, that's helpful context. Until one of those features is merged, is wrapping a step with exit 0 how the community typically works around this?
Expected Behavior
According to the docs: "Final tasks are guaranteed to be executed in parallel after all PipelineTasks under tasks have completed regardless of success or error."
Actual Behavior
If a final task references the result of a task which exited with an error, that final task is skipped.
Steps to Reproduce the Problem
Run a pipeline with:
Inspect the run to see the skipped final task:
Removing the final task's input param and using the default value instead makes the final task run as expected.
Writing something to
$(results.missing.path)
before exiting with an error does not change the behavior; a non-zero exit code seems to be sufficient to trigger this.Additional Info
I first discovered this on v0.23.0 but it affects the most recent version as well:
The text was updated successfully, but these errors were encountered: