Develop Reference

Gradle configuration cache works on local machine but fails on GitHub Actions

In gradle.properties I'm setting
org.gradle.unsafe.configuration-cache=true
This works without errors on my local machine. The output is:
0 problems were found storing the configuration cache.
When I set up a job on GitHub Actions, it only succeeds if I deactivate the configuration cache.
When it is activated I get this log:
3 problems were found storing the configuration cache, 1 of which seems unique.
- Task `:app:buildKotlinToolingMetadata` of type `org.jetbrains.kotlin.gradle.tooling.BuildKotlinToolingMetadataTask$FromKotlinExtension`: invocation of 'Task.project' at execution time is unsupported.
See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
See the complete report at file:///home/runner/work/***/***/build/reports/configuration-cache/3lar58wlvtv9703t0m3olblg9/gwoz69d8l961obatzzelsv4d/configuration-cache-report.html
> Invocation of 'Task.project' by task ':app:buildKotlinToolingMetadata' at execution time is unsupported.
My primary interest is why this behaves differently.
I'm also wondering what the best workaround is.
(Can tasks be skipped from caching? Or how would you deactivate the configuration cache on the CI server?)

I haven't understood the cause yet.
My current workaround is to disable the configuration cache on CI builds adding the option --no-configuration-cache to all gradle commands e.g.
./gradlew test --no-configuration-cache
This overwrites the setting of gradle.properties.

Android Detekt Build failed

I tried to generate code report using detekt and when execute the below command in terminal
gradle detekt
it showing build failed with below message.
* What went wrong:
Execution failed for task ':app:detekt'.
> Build failed with 395 weighted issues.

As others have said in the comments, this means you have 395 issues in your code (kind of like lint warnings).
Detekt has a maxissues: property that determines whether or not to fail the build if your issues surpass the allowed number of maxissues. What I did was search the whole project for maxissues, which will take you to your detekt-config.yml or default-detekt-config.yml. There, you can change your maxissues to whatever you want.
In our old code base, we had 900 some issues, so I changed mine from maxissues:0 to masissues:1000. As we clean up the code, I hope to bring that number down.

Re-run failed android tests

Is there a way to run only the failed set of tests on Android using Gradle?
At the moment, I run my tests as follows.
./gradle connectedDebugAndroidTest
There are tests that occasionally fail due to environment issues which are difficult to control and what I would like to do is be able to only run those failed tests and merge the result with the previous test results.
So for example, if I have 100 tests and 90 succeed, I would like to re-run the failing 10 tests. If those 10 pass the second time around, I would like to merge those results with the original test run.
It looks like this has been discussed several times for Gradle but there doesn't seem to be a solution yet.
https://github.com/gradle/gradle/issues/4068
https://github.com/gradle/gradle/issues/4450
https://github.com/gradle/gradle/issues/1283
Thanks!

The reason they don't have a way to only rerun failed tests is because it screws up the way Gradle currently works. This happens because on the first run, Gradle knows 90 tests passed. If you update the code, and then rerun only the 10 failed tests (using this new option you want them to add), then Gradle would think that all the tests have passed. However, this isn't the case because the tests which previously passed might've broken from the update which fixed the failing tests.
Despite this, the problem has been solved. Gradle reruns failed tests first, and provides a --fail-fast flag for the test task. This effectively does what you want (i.e., only reruns failed tests).

If you want to automatically rerun failed tests as part of the same build in which they failed, and succeed the build if they succeed on retry, you can use the Test Retry Gradle plugin. This will rerun each failed test a certain number of times, with the option of failing the build if too many failures have occurred overall.
plugins {
id 'org.gradle.test-retry' version '1.2.0'
}
test {
retry {
maxRetries = 3
maxFailures = 20 // Optional attribute
}
}

Realm gradle tasks

During my profile report of assembleDebug gradle task I discovered two realm related gradle sub-tasks which takes quite big amount of time:
assembleDebug - 1m21.44s
- transformClassesWithRealmOptionalAPITransformerForDebug - 22.386s
- transformClassesWithRealmTransformerForIdeDebug - 10.062s
Questions:
what exactly those realm related gradle sub tasks do? Can I skip them at some point?
why they took so long? (22 + 10 = 32 sec)
Update
As a workaround I am skipping task via -x script parameter
assembleDebug -x transformClassesWithRealmOptionalAPITransformerForDebug

transformClassesWithRealmOptionalAPITransformerForDebug is created for removing RxJava related APIs since it might create troubles for some cases (cases which need reflection like https://realm.io/docs/java/latest/#jackson-databind) which doesn't have the RxJava dependency. But we found it doesn't play well in some occasions like https://github.com/realm/realm-java/issues/3033 and https://github.com/realm/realm-java/issues/3022 . So it will be disabled in the next release after v1.0.1.
transformClassesWithRealmTransformerForIdeDebug is the core part Realm relies on. Basically it replace the field access to the RealmObject with Realm accessors by bytecode manipulating. You can see this post for a bit more details. Thus, this task cannot be skipped.
PS. an issue is created to track the transformer speed improvement.

Custom Task in Gradle (Android)

(gradle newbie question)
I am looking to run a custom task with code from this thread. This is to do with setting up build env for release/debug etc...
Since the code bloats the original boilerplate code, I would like to do following for readability and extensibility -
Move the code to separate file as a task/def(Gist of the Code
Run the task/def before assembleDebug/Release
Here are problems I face when task is appended at the end of build.gradle file:
a) If I run just the task ./gradlew buildCustom , I get error
Could not find method defaultConfig() for arguments
b) If I try to use doLast I get error
Could not find method doLast() for arguments [task ':app:assembleDebug'] on task ':app:buildCustom'.
There is something very obvious that I donot understand, appreciate any help.