PT-447: Explicitly include Android variants in analysis

[mr-archano]

Tracked by PT-447

Scope of the PR

When applying the plugin we want to skip the creation of tasks for certain Android variants to speed up the whole analysis. After discussing this with @ouchadam and @devisnik we agreed it would be cool to have an explicit way to tell the plugin which Android variants should be considered and which shouldn't.

Considerations and implementation

Each *Configurator now decorates the tool specific extension with an includeVariants method that will receive a predicate used to decide which variant should be considered as part of the analysis. Eg:

staticAnalsysis {
  findbugs {
    includeVariant { variant -> variant.name.equals('debug') }
  }
}

By default - for the moment - all variants will be included unless an explicit predicate is provided via includeVariants.

Test(s) added

Few integration tests have been added to validate that tasks related to excluded variants are not created by the plugin. Incidentally some redundant integration test has been removed because their scenarios were already covered.

[tasomaniac]

Why not using just Set?

[mr-archano]

I actually tried, but it was failing to execute addAll() with a cryptic stacktrace that sounded like a covariance issue.
The rationale of using NamedDomainObjectSet is that every project.android.*Variants is already of this type, and it supports an elegant matching() that reads better than the findAll() provided in Collection.

[tasomaniac]

Makes sense. matching is definitely looks better.

[ouchadam]

👍

[ouchadam]

how come these are """?

[mr-archano]

because of the string interpolation (ie: ${...}), you need to use GString (quoted in "") instead of simple String (using '')

[ouchadam]

ahh didn't notice the inner '' 👍

[ouchadam]

awhhh yeahh 💯

[mr-archano]

If this doesn't make you and @eduardb happy I really don't know what will :D

[ouchadam]

from what I understand, LGTM!

general question, do you have to use strings when testing the configuration inputs?

[mr-archano]

The reason why you see these strings is because how the integration tests have been designed: each integration test creates a proper Gradle project, and the strings provided in the configuration are collated in their build.gradle. Such test-projects are then run via the Gradle tooling API (Gradle running Gradle, such meta!) so we can check the outputs (generated reports, logs, tasks outputs, build success, etc).

[devisnik]

👍