KAFKA-18636 Fix how we handle Gradle exits in CI #18681
Open
+60
−61
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.
This patch also removes the non-standard exit behavior of the ":test" task. Previously, we were explicitly causing this task to fail if any test failed. This was done to prevent the results from being cached if there were flaky test runs. However, since trunk is the only CI job to write to the cache, and trunk always runs all tests (i.e., does not load the cache), it should be safe to allow caching if there were flaky tests. In fact, this should do nothing but help our PR run times as it will increase cache hits.
Here are the possible outcomes of our ":test" and ":quarantinedTest" tasks:
This not only simplifies the mapping of task outcomes to exit codes, but it aligns more closely with the way Gradle is designed and how the Develocity plugin works.