KAFKA-18636 Fix how we handle Gradle exits in CI #18681
Open
+70
−50
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch removes usages of
ignoreFailures
in our CI and changes the XML copy task to a finalizer task instead of doLast closure. Also fixes a fall-through case in junit.py where we did not recognize an error prior to running the tests (such as the javadoc task).Since we are running our CI Gradle commands with
--continue
, we should not normally need to explicitlyignoreFailures
in the test tasks. After all, that's what--continue
does (ignore failures from tasks). The reason we included it was to ensure ourdoLast
closure was always run. When a test task fails, the main task action will fail and prevent any doLast or other later parts of the task action from running.Instead of copying out the test XML in a doLast, we can use a finalizer task. A finalizer task will run regardless of task outcome. This is a bit nicer than what we were doing.
The one case where we need non-standard exit behavior is when running the main test suite on trunk. We may have flaky re-runs of tests which allow the ":test" task to exit normally. However, we do not want to cache the test results if there were flaky failures as this may potentially "hide" flaky tests from our PRs. So far, the only way we have determined to prevent a task from being cached is for it to fail.
Here are the possible outcomes of our ":test" task:
For our ":quarantinedTest" task:
The only difference is in the "Flaky failures" behavior.