Implement Worker API for VerifyPluginTask

[alajemba-vik]

Pull Request Details

Updated VerifyPluginTask to delegate task action to VerifyPluginWorkAction to leverage Worker API

Description

classes VerifyPluginWorkAction and VerifyPluginWorkParameters were added to implement Worker API functionality. The VerifyPluginTask was updated to extend DefaultTask instead of JavaExec because it is no longer directly delegating work to the intellijPluginVerifier but allowing the WorkAction class to do so instead.
Only the necessary information for each submitted work action is defined in the VerifyPluginWorkParameters

Motivation and Context

Improve the performance of the VerifyPluginTask

How Has This Been Tested

Compared the outputs of the VerifyPluginTask before and after the Worker API implementation
Compared the Build Scan results of running the verifyPlugin task before integrating Worker API and after the integration

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have included my change in the CHANGELOG.
• I have added tests to cover my changes.
• All new and existing tests passed.

[alajemba-vik]

These changes will result in a race condition if there are several ides we are trying to verify. The submitted work actions end up deleting the same verification reports directory.
Potential solutions I can think of for now:

• Allow each work action to accept a different verification reports directory
• Delete the verification reports directory before you submit the work action
  @hsz

[alajemba-vik]

Additionally, the ides to use in plugin verification is resolved before task execution. Waiting for all ides to download before going on to execute the task action is one of the major delays.
Considering resolving the ides during task execution? That way, we don't have to wait for all the ides to download before we start verifying.

[hsz]

These changes will result in a race condition if there are several ides we are trying to verify. The submitted work actions end up deleting the same verification reports directory. Potential solutions I can think of for now:

• Allow each work action to accept a different verification reports directory
• Delete the verification reports directory before you submit the work action
  @hsz

Different report directories should do the job – each report should be stored within a directory named by the IDE we use for testing.

[hsz]

Additionally, the ides to use in plugin verification is resolved before task execution. Waiting for all ides to download before going on to execute the task action is one of the major delays. Considering resolving the ides during task execution? That way, we don't have to wait for all the ides to download before we start verifying.

Are you sure that IDEs are resolved before the task execution? I'd rather assume that the ides collection is resolved when we start looping over it. Or maybe not, and it's calculated (therefore resolved) yet in the configuration phase.

You can try moving the following part right into the task's action:

intellij-platform-gradle-plugin/src/main/kotlin/org/jetbrains/intellij/platform/gradle/tasks/VerifyPluginTask.kt

Lines 309 to 321 in 23ee90b

	ides = project.files(project.provider {
	with(intellijPluginVerifierIdesConfiguration.incoming.dependencies) {
	if (size > 5) {
	val ideList = joinToString(", ") { "${it.group}:${it.name}:${it.version}" }
	log.warn("The ${Tasks.VERIFY_PLUGIN} task is about to resolve $size IDEs: $ideList")
	}
	flatMap {
	project.configurations.detachedConfiguration(it).apply {
	attributes { attribute(Attributes.extracted, true) }
	}.resolve()
	}
	}
	})

This will surely violate the configuration cache, but our task is already untracked, so nothing should fail, I believe.

[hsz]

Please remember about the apiCheck and apiDump tasks.