Gradle should warn users in case of conflicting ArtifactTransform registrations

[britter]

Expected Behavior

Given I register a transform from attribute foo to attribute bar,
when I register another transform from attribute foo to attribute bar,
Gradle should fail the build, notifying me about the conflicting registrations.

Current Behavior (optional)

Boths transforms are registered. During transform execution the transform that was registered first is selected leading to surprising behavior.

Context

We have a pattern in our build for downloading and unpacking binaries. We use custom Ivy repositories to model GitHub release pages. Then in case we download an archive, we register transforms in order unpack the binary just once instead of having unpack tasks registered in each project. See the 'Modeling downloadable resources using Ivy repositories' section in this issue. Usually we create a plugin that deals with all of this logic. We might have a buildlogic.helm plugin that takes care of downloading the helm CLI, and then another plugin buildlogic.chromedriver that download chromedriver.

Recently I had to download GitHub CodeQL CLI which is provided as a Zip archive here. First I tried using org.gradle.api.internal.artifacts.transform.UnzipTransform for unpacking, because we use it in a few other places, but that didn't work, because UnzipTransform does not restore file permissions from the Zip. So I created my own transform that reads the file permissions from the archive and restores them on the file. The code looked something like this:

// contents of `buildlogic.codeql.gradle.kts`

val os = OperatingSystem.current()

val osFilenamePart =
    when {
        os.isMacOsX -> "osx64"
        os.isWindows -> "win64"
        else -> "linux64"
    }

// TODO move to commonVersions
val codeQlCliVersion = provider { "2.17.0" }

repositories {
    exclusiveContent {
        forRepository {
            ivy {
                url = uri("https://github.com/github/")
                patternLayout {
                    artifact("[organization]/releases/download/v[revision]/[artifact]-[classifier].[ext]")
                }
                metadataSources {
                    artifact()
                }
            }
        }
        filter {
            includeModule("codeql-cli-binaries", "codeql")
        }
    }
}

val codeQlBinary by configurations.creating {
    isCanBeResolved = true
    isCanBeConsumed = false
    attributes.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, ArtifactTypeDefinition.DIRECTORY_TYPE)
}

dependencies {
    registerTransform(ExplodeCodeQlTransform::class) {
        from.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, ArtifactTypeDefinition.ZIP_TYPE)
        to.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, ArtifactTypeDefinition.DIRECTORY_TYPE)
    }
    codeQlBinary(codeQlCliVersion.map { "codeql-cli-binaries:codeql:$it:$osFilenamePart@zip" })
}

tasks.withType<CodeQlCliExec>().configureEach {
    dependsOn(codeQlBinary)
    codeQlDist.fileProvider(provider { File(codeQlBinary.singleFile, "codeql") })
    codeQlVersion = codeQlCliVersion
}

This code worked for most of the projects I applied the plugin to. However if failed for two projects reporting a file permission error. After lots of digging, I realized that for the two projects we register another "download executable plugin" and that plugin registers org.gradle.api.internal.artifacts.transform.UnzipTransform for the same attributes. Because the other plugin was registered first in the failing projects, Gradle selected the UnzipTransform and ignored the transform that would restore file permissions.

The workaround for this was to use a different to attribute setting to make transform registrations unique. However I think having multiple transforms registered for the same set of attributes should cause an error.

[ov7a]

This issue will be closed as a duplicate of

• Registering multiple transforms with the same values of attributes should fail #26974

Please add your use case and 👍 to that issue.

If you think our analysis is wrong, please provide us with more detailed information explaining why.