Stop invoking bitrise cache for tasks Gradle task.

[designedbyz]

I was poking around at the cache utilization diagnostics where I work and noticed a rather interesting trend: approximately 25% of our cache invocations were for tasks --all, a gradle task that the diagnostics report is not cacheable because it takes the entire project state as an input:

We don't directly invoke the tasks task in any of our workflows, so I started tracing it down and found that it was mostly called by the Android lint and unit test Bitrise steps. Those steps in turn make use of the GetVariants function defined in this repository, which appears to be where tasks --all is invoked.

Passing the --no-build-cache flag to Gradle at execution time should disable the build cache for the tasks task and fix the problem. There may be a slight risk that this increases build times for customers with significantly complex buildSrc or included build logic, but in testing with a local cache in our project I couldn't figure out a way to cause those tasks to come from the cache anyways.

This may also might not be the only solution, there'd be several efficient ways to do this with a custom Gradle plugin, this is just what appeared to me to be the simplest solution given my lack of experience with the step framework

[zsolt-marta-bitrise]

Thank you for your contribution!

The invocation you see in your list comes from the analytics plugin and we don't apply any kind of filter on the commands (as you can call this task deliberately too). If you disable the build cache, it will just disable the build cache plugin, not the analytics, so it will still show up. There is no way of disabling the plugin for a single invocation, since it's not a standard Gradle feature but our own analytics plugin applied by the init script.

You can opt out from analytics by setting the Collect Gradle build metrics flag to false in the Activate Bitrise Build Cache Add-On for Gradle step. But I discourage this as the analytics provides useful insights into task performance, dependencies (critical path), execution reasons, build performance and cache utilization trends.

You can apply configuration cache if your project supports it to speed this task up (as basically this task doesn't do anything significant after that)