Skip to content
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

Refine GRADLE_RERUNNER #8522

Merged
merged 4 commits into from Feb 19, 2019
Merged

Refine GRADLE_RERUNNER #8522

merged 4 commits into from Feb 19, 2019

Conversation

blindpirate
Copy link
Collaborator

@blindpirate blindpirate commented Feb 15, 2019

Context

This is the followup of #8470 : there're two issues unresolved:

  • GRADLE_RERUNNER is configured to Gradleception/compileAll/sanityCheck, etc. , which makes no sense.
  • We want to skip GRADLE_RERUNNER if there're too many failures.

This PR does:

  • Extract another function applyTestDefaults in addition to applyDefaults. Functional test build and smoke test build apply applyTestDefaults.
  • Slightly refactor applyDefaults function.
  • Add unit tests for applyTestDefaults/applyDefaults.
  • Switch to JUnit 5 for .teamcity project.
  • Ignore the rerun if test failures are > 10.

@blindpirate blindpirate self-assigned this Feb 15, 2019
@blindpirate blindpirate added from:member a:chore Minor issue without significant impact @dev-productivity Issue owned by developer-productivity labels Feb 15, 2019
<kotlin.version>1.3.0</kotlin.version>
<teamcity.dsl.version>2018.2</teamcity.dsl.version>
<mockk.version>1.9</mockk.version>
<junit.version>5.4.0</junit.version>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switch to JUnit 5 because I don't see any reasons no doing so.

</snapshots>
</repository>
</repositories>
<repositories>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indents are adjusted because this is IDEA-default.

@@ -221,7 +235,7 @@ class UnitTestAndCompilePlugin : Plugin<Project> {
fun Test.onlyRunPreviousFailedClassesIfNecessary() {
if (project.stringPropertyOrEmpty("onlyPreviousFailedTestClasses").toBoolean()) {
val previousFailedClasses = getPreviousFailedTestClasses()
if (previousFailedClasses.isEmpty()) {
if (previousFailedClasses.isEmpty() || allTestFailuresCount.get() > tooManyTestFailuresThreshold) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be not accurate enough. For example, a build contains two test tasks, test task A has 8 failures, test task B has 6 failures, then both A and B should be disabled, but this logic will only disable test task B. I guess this is fine, we can adjust this logic and the threshold 10 if there's evidence they're not good enough.


val buildScanTags = model.buildScanTags + listOfNotNull(buildType.stage?.id)
private
fun checkCleanM2Step(buildType: BaseGradleBuildType, os: OS = OS.linux) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be an extension function on BaseGradleBuildType?

Same goes for the other methods adding steps.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I was running into some issues previously when I tried to use extension function. Now I've fixed them.


addKillProcessStep("KILL_PROCESSES_STARTED_BY_GRADLE")
private
fun gradleRerunnerStep(model: CIBuildModel, buildType: BaseGradleBuildType, gradleTasks: String, os: OS = OS.linux, extraParameters: String = "", daemon: Boolean = true) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it makes sense to extract the common code and add a new flag (something like rerunFailedTest: Boolean instead of duplicating most of the logic?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I think current code is more clear to say "which build steps we have":

    buildType.gradleRunnerStep(model, gradleTasks, os, extraParameters, daemon)

    buildType.steps.extraSteps()

    buildType.checkCleanM2Step(os)
    buildType.verifyTestFilesCleanupStep(daemon)
    buildType.tagBuildStep(model, daemon)

So I'd probably prefer this way.

class UnitTestAndCompilePlugin : Plugin<Project> {
private
val allTestFailuresCount = AtomicInteger(0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is per project, isn't it? I think that is fine, though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Anyway we're running tests per project on CI, so that's fine.

@@ -88,7 +89,18 @@ enum class ModuleType(val compatibility: JavaVersion) {
}


/**
* By default, we run an extra build step ("GRADLE_RERUNNER") which runs all test classes failed in the previous build step ("GRADLE_RUNNER").
* However, if previous test failures are too many (>10), this is probably not caused by flainess.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: typo in flakiness

@blindpirate
Copy link
Collaborator Author

@wolfs PTAL

@blindpirate blindpirate merged commit 900592a into master Feb 19, 2019
@blindpirate blindpirate deleted the blindpirate/refine-rerunner branch February 19, 2019 01:07
@blindpirate
Copy link
Collaborator Author

Thanks @wolfs !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:chore Minor issue without significant impact @dev-productivity Issue owned by developer-productivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants