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

[Question] Exclude Certain flavor & Build Type #945

Open
rezastallone opened this issue Aug 21, 2023 · 15 comments
Open

[Question] Exclude Certain flavor & Build Type #945

rezastallone opened this issue Aug 21, 2023 · 15 comments
Labels
documentation Improvements or additions to documentation question Further information is requested toolchain:android
Milestone

Comments

@rezastallone
Copy link

rezastallone commented Aug 21, 2023

My project currently has 17 flavor & 4 build type, that means 68 combination of build type & flavor task and additional task generated for each combination. I have managed to exclude flavor & build type using the following script

gradle.taskGraph.whenReady { graph ->
    if (project.hasProperty("onlyDebug")) {
        def targetTaskPatterns = [
                /(?i).*androidTest.*/
                , /(?i).*UnitTest.*/
                , /(?i).*Release.*/
                , /(?i).*Benchmark.*/
                , /(?i).*BenchmarkKotlin.*/
                , /(?i).*MockKotlin.*/
                , /(?i).*Mock.*/
                , /(?i).*Production.*/
                , /(?i).*PreSubAutomation.*/
                , /(?i).*Preprod.*/
                , /(?i).*Sit04.*/
                , /(?i).*Sit03.*/
                , /(?i).*Sit02.*/
                , /(?i).*Sit01.*/
                , /(?i).*Publicsit.*/
                , /(?i).*Sandbox2.*/
                , /(?i).*Sandbox.*/
                , /(?i).*Integration06.*/
                , /(?i).*Integration05.*/
                , /(?i).*Integration04.*/
                , /(?i).*Integration03.*/
                , /(?i).*Integration02.*/
                , /(?i).*Integration01.*/
        ]

        graph.allTasks.each { task ->
            targetTaskPatterns.each { pattern ->
                if (task.name =~ pattern) {
                    println("Match pattern to disable")
                    println(task.name)
                    task.enabled = false
                }
            }
        }
    }
}

However, it seems task "> A failure occurred while executing com.autonomousapps.tasks.ComputeAdviceTask$ComputeAdviceAction"
still expect all flavor and build type to be compiled somehow because i got this error
"app/build/reports/dependency-analysis/integration01DebugTest/graph/graph-compile.json (No such file or directory)"

Is there a way to exclude certain flavor & build type so i can run this plugin faster without compiling all combination of flavor & build type ?

Thank you

@rezastallone
Copy link
Author

Aditionally, I was able to make it run only 1 combination of build type & flavor by manually comment out build type & flavor.

@rezastallone
Copy link
Author

What i am looking for is like Sonarcube configuration where you can choose certain build flavor so you dont run all combination of build types and flavor

sonarqube {
    androidVariant 'dev01Debug'
    ...
}

@autonomousapps
Copy link
Owner

autonomousapps commented Aug 23, 2023

Thanks for the question. Your methodology for excluding variants (disabling tasks) is not the right way to go about it. Instead, please use the appropriate AGP API. See the docs here.

Alternatively, you could use the flag -Pdependency.analysis.android.ignored.variants=variant1,variant2,variant3 to ignore specific Android variants. This is since v1.18.0.

@autonomousapps autonomousapps added question Further information is requested toolchain:android labels Aug 23, 2023
@rezastallone
Copy link
Author

Thanks for the question. Your methodology for excluding variants (disabling tasks) is not the right way to go about it. Instead, please use the appropriate AGP API. See the docs here.

Alternatively, you could use the flag -Pdependency.analysis.android.ignored.variants=variant1,variant2,variant3 to ignore specific Android variants. This is since v1.18.0.

Thank you, i'll check this out

@matejdro
Copy link

matejdro commented May 17, 2024

Variant exclusion does not work for all use cases. For example, as far as I can see, disabling instrumented tests can only be achieved by disabling their tasks (and dependency.analysis.android.ignored.variants does not help here)

EDIT: disabling by source set might help here. Will check it out.

@matejdro
Copy link

matejdro commented May 24, 2024

I found a workaround for this: exclude this plugin from blanked task disabling. I do this by checking task.javaClass.name.startsWith("com.autonomousapps"). It's not ideal, but at least it doesn't crash.

@ParaskP7
Copy link

ParaskP7 commented May 28, 2024

👋 @autonomousapps !

I too I have been experiencing issues with the ignoring Android variants flag that got introduced with #814 and 1.18.0. The only way for me to exclude variants from the projects I am working with (project like woocommerce-android) is to use a custom configuration (commit). As such, the dependency.analysis.android.ignored.variants=variant1,variant2,variant3 flag seems to not work as expected, not at least for this project.

My assumption is that although the dependency.analysis.android.ignored.variants could work when a project/module utilizes build types (debug, release, etc), it stops working as expected when a project/module also utilizes product flavors. As such, maybe this issue is closely related to variants with a combination of product flavors and build types. 🤔


For woocommerce-android, I --dry-run the buildHealth task for you, once without the ignored variants configuration, and once with the most simple version of an ignored variants configuration (dependency.analysis.android.ignored.variants=release).

The result below:

If you compare these 2 files you will notice that the ignored variants configuration works for simple modules like libs:cardreader and libs:iap, for which product flavors don't apply, but don't on modules like WooCommerce, which is also utilizing product flavors, that is of course, in addition to build types.

Note

You will find these changes within the build/dependency-analysis-android-gradle-plugin branch, just in case you would like to clone/pull the repo/branch and experienced it for yourself.


I hope all this info will somewhat help you with your investigation, and thank you! 🙏

Cc @sboishtyan

@sboishtyan
Copy link
Contributor

sboishtyan commented May 28, 2024

@ParaskP7 Hey, I could check your hypothesis this week.
If I could reproduce I would even try to figure out a reason and fix this behaviour.

@ParaskP7
Copy link

👋 @sboishtyan and thanks so much for jumping right into that to help out, much appreciated. I am really looking forward to whatever insights you can find on this issue, good luck! 🍀

@sboishtyan
Copy link
Contributor

@ParaskP7 Could you provide a set up branch for me. Because according to your README file I should setup a project. But I think it would be better if you do it for me.
And also we could use that branch in the future for reproduce problems

@ParaskP7
Copy link

👋 @sboishtyan !

@ParaskP7 Could you provide a set up branch for me. Because according to your README file I should setup a project. But I think it would be better if you do it for me.

For sure, I actually left you a note on that on my initial comment above, see below:

Note

You will find these changes within the build/dependency-analysis-android-gradle-plugin branch, just in case you would like to clone/pull the repo/branch and experienced it for yourself.

As such, you can use this branch.

FYI: In general, the only think you would really need after cloning this repo is to copy-paste the gradle.properties-example file into gradle.properties and that's it, as simple as: cp gradle.properties-example gradle.properties

Let me know how that works for you! 🙏

PS: Please ignore all the other setup steps (like the OAuth2 Authentication and Configuration Files sections) as those are for when you actually want to test the project. This setup is not needed for building purposes.

And also we could use that branch in the future for reproduce problems

Exactly! 💯

@sboishtyan
Copy link
Contributor

Hi @ParaskP7
So I checked out your branch

Then I commented code in ignored_variants.gradle
Then I added a line to gradle.properties
dependency.analysis.android.ignored.variants=vanillaDebug,vanillaRelease,wasabiDebug,jalapenoDebug,jalapenoRelease
Then I ran ./gradlew --dry-run buildHealth
And then I saw the expected output that everything except wasabiRelease was excluded from the analysis
worked_output.txt

So, I propose you apply those changes and check the output.
In case of incorrect result please add an extra commit to your branch where you configure thedependency.analysis.android.ignored.variants property

@ParaskP7
Copy link

ParaskP7 commented Jun 4, 2024

👋 @sboishtyan and thank you for looking into it, much appreciated! 🙇

Then I added a line to gradle.properties
dependency.analysis.android.ignored.variants=vanillaDebug,vanillaRelease,wasabiDebug,jalapenoDebug,jalapenoRelease
Then I ran ./gradlew --dry-run buildHealth
And then I saw the expected output that everything except wasabiRelease was excluded from the analysis
worked_output.txt

Ah, actually, you are right, with this dependency.analysis.android.ignored.variants configuration that you present above, those variants are indeed being excluded. I didn't realize that you need to add each variant like that. For some reason, I was trying the following configuration instead:

dependency.analysis.android.ignored.variants=release,vanilla,jalapeno

I was (incorrectly) thinking that the above is enough to exclude all the release build type kind of variants, and then the vanilla + jalapeno product flavor kind of variants. However, it seems that we need to explicitly add each variant in that configuration. Thanks so much for this clarification. 🙏

Btw, just for completeness purposes, for me to be able to run buildHealth the way I intended it to, I also needed to add debug into the dependency.analysis.android.ignored.variants configuration you shared. Otherwise, the debug build type on all library related modules would NOT be excluded. Maybe this is what confused me in the first place... 🤷

So ultimately, what is working for me and this project is the following configuration, that is if I want for the dependency analysis to run for the wasabiRelease app variant and the release lib variants only:

dependency.analysis.android.ignored.variants=debug,vanillaDebug,vanillaRelease,wasabiDebug,jalapenoDebug,jalapenoRelease


FYI: For this other WordPress-Android project that I am also working on, which has a more complicated product flavor configuration, based on above, I had to then apply the following configuration, it worked: 🎉

dependency.analysis.android.ignored.variants=release,wordpressVanillaDebug,wordpressVanillaRelease,wordpressWasabiDebug,wordpressWasabiRelease,wordpressJalapenoRelease,jetpackVanillaDebug,jetpackVanillaRelease,jetpackWasabiDebug,jetpackWasabiRelease,jetpackJalapenoRelease

The above would run the dependency analysis for the jetpackJalapenoDebug app variant and the debug lib variants only.

Again, I was initially trying something like the below, thinking it should work:

dependency.analysis.android.ignored.variants=release,wordpress,vanilla,wasabi

Question (❓): Wouldn't the above configuration be feasible with an update. Or, is it better to be explicit, enumerating exactly which variants one would like to ignore, wdyt? 🤔


No matter, your answer solved my issue and any concerns. I can now effectively use this dependency.analysis.android.ignored.variants=xyz configuration. Thanks you so much for all the work! 🥇

Suggestion (💡): Btw, do you think it is maybe worth adding a wiki page explaining all what we discussed here? Maybe also providing to any readers with examples on how to properly use this configuration, especially when product flavors are involved.

@sboishtyan
Copy link
Contributor

@ParaskP7 I agree that without the context it's easy to misinterpret what set as a value to a flag.
@autonomousapps What do you think about adding extra explanations and examples to flag dependency.analysis.android.ignored.variants

I could add a PR and also add a link to this issue

@autonomousapps autonomousapps added the documentation Improvements or additions to documentation label Jun 13, 2024
@autonomousapps autonomousapps added this to the next milestone Jun 13, 2024
@autonomousapps
Copy link
Owner

autonomousapps commented Jun 13, 2024

My thinking with the original property name is that "variant" in the Android world has always referred to the full variant name, that is, the combination of buildType and flavor. The way this is implemented is very simple:

androidComponents.onVariants { variant ->
  if (variant.name !in ignoredVariantNames) {
    // analyze!

I worry about the complexity of handling buildType vs flavor separately, and trying to somehow interpret the user's meaning. Better documentation would certainly be useful though. I appreciate the feedback 👍

For the record, PRs are also welcome, but I may decide not to accept a patch if I think the additional complexity is too much to maintain (I'm the sole maintainer of this project).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation question Further information is requested toolchain:android
Projects
None yet
Development

No branches or pull requests

5 participants