-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gradle check retry #2638
Gradle check retry #2638
Conversation
build.gradle
Outdated
apply plugin: "org.gradle.test-retry" | ||
tasks.withType(Test).configureEach { | ||
retry { | ||
if (isCiServer) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could probably just not configure the task if it is not CI:
if (isCiServer) {
tasks.withType(Test).configureEach {
retry {
....
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I would highly recommend to set maxFailures
to some reasonable value, 5
for example:
* The maximum number of test failures that are allowed before retrying is disabled.
Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should start by retrying once (maxRetries = 1
), which should weed out some of the worst offenders and point us to the failures we should focus on fixing. Otherwise we'll start relying on retries too much. WDYT?
I would make maxFailures
a bit larger to really capture broken code vs. multiple flukes, like maybe 10, but don't feel strongly about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would really benefit from something like gradle/test-retry-gradle-plugin#29 for our use case to catch the worst offenders.
I agree with giving it a kick start with 1-2 retries and stopping on multiple test failures. From what I have noticed, it usually takes 2 retries recently to get it going. But let's start small enough to give a boost and not over rely.
I'll update the PR with { maxFailures = 10, maxRetries = 1 }
.
The fact that gradle check succeeded here from the first try tells me that we're on the right track :) |
Signed-off-by: Kunal Kotwani <[email protected]>
Another random failure. Runs fine on my devbox -
|
start gradle check |
@kotwanikunal Did it retry |
@kotwanikunal @dblock I believe the
We do some tricks here as well https://github.com/opensearch-project/OpenSearch/blob/main/gradle/code-coverage.gradle#L47 |
It only retries the failing tests. I verified that on my local machine with different scenarios including In the individual project logs, you usually see I will try force failing an |
It does infact cover the I ran It looks like it retries the failing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! If maxRetries = 1
is too noisy, I am ok with 2 or 3.
About Its direct type is |
What wired here is I didn't see the retry occurs in the above failed gradle check, in the "Reports 3865" |
@kotwanikunal use
|
@reta How about adding in a single retry for dev and CI for now? |
Let's vote and if we have a deadlock, we'll just try again? :) I'm good with anything. |
I am fine with that ... for now |
Signed-off-by: Kunal Kotwani <[email protected]>
How do we ensure we aren't swallowing failures with reproducible seeds? Does it retry with the same seed? |
I am not 100% sure but I would doubt the seed is preserved |
Aha, this one seems to retried And same seed was used
@mch2 ^^ @dblock seems like 1 retry is not enough ... or we need to retry the while suite? |
Open issue for this test: #1703 |
Retrying the whole suite will make it difficult to pinpoint flakiness to particular tests. This helps us get to the most frequent offenders IMHO. |
I agree, I don't like that at all, thinking loudly - if cluster ended up in "bad" ( == not expected) state at startup, the test may never succeed ... but we should consider that to be separate problem I guess |
Do you want to increase the number of retries @kotwanikunal? |
Signed-off-by: Kunal Kotwani <[email protected]>
* Add retry plugin support for Test implementations Signed-off-by: Kunal Kotwani <[email protected]> * Update test retry parameters Signed-off-by: Kunal Kotwani <[email protected]> * Remove CI environment check for test retries Signed-off-by: Kunal Kotwani <[email protected]> * Update retry count for tests Signed-off-by: Kunal Kotwani <[email protected]> (cherry picked from commit 65cc56e)
* Add retry plugin support for Test implementations Signed-off-by: Kunal Kotwani <[email protected]> * Update test retry parameters Signed-off-by: Kunal Kotwani <[email protected]> * Remove CI environment check for test retries Signed-off-by: Kunal Kotwani <[email protected]> * Update retry count for tests Signed-off-by: Kunal Kotwani <[email protected]> (cherry picked from commit 65cc56e)
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.x 1.x
# Navigate to the new working tree
cd .worktrees/backport-1.x
# Create a new branch
git switch --create backport/backport-2638-to-1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 65cc56e754e4a854963663ead5d06ea6e975d1eb
# Push it to GitHub
git push --set-upstream origin backport/backport-2638-to-1.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.x Then, create a pull request where the |
Add retry plugin support for Test implementations Signed-off-by: Kunal Kotwani <[email protected]> (cherry picked from commit 65cc56e) Co-authored-by: Kunal Kotwani <[email protected]>
Add retry plugin support for Test implementations Signed-off-by: Kunal Kotwani <[email protected]> (cherry picked from commit 65cc56e)
@kotwanikunal Would you backport the change into 1.x branch? |
* Add retry plugin support for Test implementations Signed-off-by: Kunal Kotwani <[email protected]> * Update test retry parameters Signed-off-by: Kunal Kotwani <[email protected]> * Remove CI environment check for test retries Signed-off-by: Kunal Kotwani <[email protected]> * Update retry count for tests Signed-off-by: Kunal Kotwani <[email protected]> (cherry picked from commit 65cc56e)
* Adds a retry mechanism for all test classes under the root project * This will help with gradle check failed by flaky tests Signed-off-by: Kunal Kotwani <[email protected]> (cherry picked from commit 65cc56e)
Description
gradle check
failuresIssues Resolved
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.