tooling/templatize: record preemtped steps as skipped in jUnit #3922
Conversation
Previously, we would record any error in a step as a failed jUnit test case. However, when one step fails, we cancel the context the rest of the steps use to run, and any other currently-running steps end up in the blast radius. Investigating those failures is not useful, as they give no unique information. Let's record them as skipped so that overall views of "highest failure rate test this week" don't pick up whichever pipeline step runs the longest and is the most susceptible to getting preempted. Signed-off-by: Steve Kuznetsov <[email protected]>
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bennerv, mbukatov, stevekuznetsov The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/override ci/prow/e2e-parallel flakes on federated msi |
|
@stevekuznetsov: Overrode contexts on behalf of stevekuznetsov: ci/prow/e2e-parallel DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
openshift-merge-bot
bot
deleted the
skuznets/fix-cancelled-pipeline-steps
branch
Previously, we would record any error in a step as a failed jUnit test case. However, when one step fails, we cancel the context the rest of the steps use to run, and any other currently-running steps end up in the blast radius. Investigating those failures is not useful, as they give no unique information. Let's record them as skipped so that overall views of "highest failure rate test this week" don't pick up whichever pipeline step runs the longest and is the most susceptible to getting preempted.