You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We have a lot of fake/demo/testing style projects that are only intended for consumption by debug variant apps. Some of these have only debug/ sourcesets. In a perfect world, we would use single-variant android libraries and rely on other tooling to ensure these projects never end up in release builds. Our current state leaves us with a lot of complications if we try to run analysis on both debug and release variants because these debug-only projects often fail to compile in the release configuration, or we are just wasting time by analyzing releaseUnitTest stuff.
I'd propose this as an intermediate solution until a v3.0 where we might have a more advanced DSL for exclusions. What I'd really like to do is be able to exclude release variants for test source sets everywhere.
The reason will be displayed to describe this comment to others. Learn more.
Why is this on the AbiHandler? The way it's used, it looks like it's causing the variant to be ignored for all use-cases, not just ABI analysis. And given that, why isn't the existing functionality to ignore specific source sets sufficient?
I got it mixed up with the ProjectIssueHandler handler, what I was going for was a project specific version of the global property dependency.analysis.android.ignored.variants that exists currently.
If I have an Android project with only a debug/ source set, and I use ignoreSourceSet('release') DAGP still compiles and analyzes the variant (or it tries to and fails because the release configuration of some of these debug-only projects is often broken).
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We have a lot of
fake/demo/testingstyle projects that are only intended for consumption by debug variant apps. Some of these have onlydebug/sourcesets. In a perfect world, we would use single-variant android libraries and rely on other tooling to ensure these projects never end up in release builds. Our current state leaves us with a lot of complications if we try to run analysis on both debug and release variants because these debug-only projects often fail to compile in the release configuration, or we are just wasting time by analyzingreleaseUnitTeststuff.I'd propose this as an intermediate solution until a v3.0 where we might have a more advanced DSL for exclusions. What I'd really like to do is be able to exclude release variants for test source sets everywhere.