IssueTracker

Tentatively, this is a test inside buildSrc-tests where we construct a Project that depends on tip-of-tree-versioned prebuilts. I... think that's possible? We may need to chain a GradleRunner that builds the artifacts using the "real" project against one that builds a synthetic project using the output directory as a local Maven repository.

That sounds reasonable to me

Sample usage of a GradleRunner: https://android.googlesource.com/platform/frameworks/support/+/e5a9e50fd59340bd1b846cb4a3df64d60219fecc/buildSrc-tests/project-subsets/src/test/kotlin/androidx/build/ProjectSubsetsTest.kt#69

I think if :buildSrc-tests:metadata-verifier:verify (or whatever we want to call it) dependsOn :createArchive then it should be able to re-use the existing metadata files that go into out/androidx/build/support_repo

I wonder if it would be interesting to be able to verify a single artifact without building all the other artifacts. We could potentially add a task to each project and call it something like verifyGeneratedMetadata and have it verify the .aar/.pom/.module files for that particular project

I think if :buildSrc-tests:metadata-verifier:verify (or whatever we want to call it) dependsOn :createArchive then it should be able to re-use the existing metadata files that go into out/androidx/build/support_repo

Interesting! In that scenario, what would the verify task be doing? Is that a placeholder for the task that runs the buildSrc-tests test suite?

Or, I guess we wouldn't want our buildSrc-test unit tests to depend on :createArchive so maybe this is a separate test module.

I think if :buildSrc-tests:metadata-verifier:verify (or whatever we want to call it) dependsOn :createArchive then it should be able to re-use the existing metadata files that go into out/androidx/build/support_repo

Interesting! In that scenario, what would the verify task be doing? Is that a placeholder for the task that runs the buildSrc-tests test suite?

Yeah, I think if we have one or more tasks that dependsOn :createArchive to verify the corresponding .aar/.pom/.metadata file then that should allow us to check the files after they get built.

Or, I guess we wouldn't want our buildSrc-test unit tests to depend on :createArchive so maybe this is a separate test module.

That's reasonable, that developers might be surprised if a task in :buildSrc-tests triggers the building of all of the projects (I'm imagining that if we take this approach then task would be separate from the existing unit-test test task anyway so the unit tests wouldn't actually depend on :createArchive). Making a new project seems reasonable to me. Alternatively we could move buildSrc-tests to build-tests/unit and then also make build-tests/integ or something like that.

Another option if we're satisfied with simply resolving the dependencies is we can ask each project to verify its own metadata files. It should be possible to create a Configuration (via DetachedConfiguration: https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/ConfigurationContainer.html#detachedConfiguration-org.gradle.api.artifacts.Dependency...- ) and resolve it within some new task without adding it as a named Configuration in the project. Then we can make that new task (maybe :subproject:verifyMetadata) be a dependency of :subproject:buildOnServer (might have to create that task too) and make it depend on :subproject:createArchive to get us closer to :subproject:buildOnServer doing all of the relevant checks for an artifact

Then we can make that new task (maybe :subproject:verifyMetadata) be a dependency of :subproject:buildOnServer (might have to create that task too) and make it depend on :subproject:createArchive to get us closer to :subproject:buildOnServer doing all of the relevant checks for an artifact

This seems like the better option; however, we won't be able to integration test projects in complete isolation since we will need to run createArchive for all tip-of-tree dependencies (and transitive dependencies). We may want to make that optional? We definitely have projects where we need to be testing Gradle Metadata because they are constraints and projects where we need to be testing Proguard because they are defining custom rules, but I think the vast majority of projects wouldn't benefit from an integration test.

I think we're not going to get as much benefit from this as we have from other prevention strategies from the retrospective. Punting.