Closed xwjiang-ms closed 3 months ago
Parameter STOP_ON_FAILURE: "False"
and STOP_ON_FAILURE: "False"
will promise this checker will always return success
, unless the elastic test failed due to some transient issues. So, I think there is no confusion now.
Parameter
STOP_ON_FAILURE: "False"
andSTOP_ON_FAILURE: "False"
will promise this checker will always returnsuccess
, unless the elastic test failed due to some transient issues. So, I think there is no confusion now.
Parameter would not stop testplan, but testplan failure would still cause failure for onboarding jobs, like lock testbed failure, sanity check/testbed issue, so it's needed to add an optional keyword to reduce confusion
Description of PR
Summary: Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
Onboarding test jobs are optional test jobs, we are using it in piloting, but some contributors were confused with failed onboarding jobs
How did you do it?
Add an optional keyword to reduce confusion
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation