[Bug] Using nested actions from Gradle doesn't work

[krzema12]

Component

• github-workflows-kt (library with the DSL)
• bindings server (https://bindings.krzeminski.it)
• I don't know

Action

Use an action that is not in some repo's root directory, from a Gradle project:

implementation("gradle:actions__setup-gradle:v4")

Expected

Works like with Kotlin Scripting.

Actual

Configuration cache state could not be cached: field `provider` of `org.gradle.internal.serialize.codecs.core.ProviderBackedFileCollectionSpec` bean found in field `element` of `java.util.Collections$SingletonList` bean found in field `elements` of `org.gradle.internal.serialize.codecs.core.ResolutionBackedFileCollectionSpec` bean found in field `__classpathSnapshot__` of `org.jetbrains.kotlin.gradle.tasks.KotlinCompile$ClasspathSnapshotProperties` bean found in field `__classpathSnapshotProperties__` of task `:github-workflows-kt:compileTestKotlin` of type `org.jetbrains.kotlin.gradle.tasks.KotlinCompile`: error writing value of type 'org.gradle.api.internal.provider.DefaultProvider'
For more on this, please refer to https://docs.gradle.org/8.10.2/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
> Could not resolve all files for configuration ':github-workflows-kt:testCompileClasspath'.
10 actionable tasks: 4 executed, 6 from cache
   > Could not resolve gradle:actions__setup-gradle:v4.
     Required by:
         project :github-workflows-kt
      > Could not resolve gradle:actions__setup-gradle:v4.
         > inconsistent module metadata found. Descriptor: gradle:actions/setup-gradle:v4 Errors: bad module name: expected='actions__setup-gradle' found='actions/setup-gradle'

Reproducer: #1693

Workaround, if exists

repositories {
    maven {
        ...
        metadataSources {
            artifact()
        }
    }
}

[krzema12]

Noticed by @mareklangiewicz.

[krzema12]

I suspect we'd need to adjust

github-workflows-kt/maven-binding-builder/src/main/kotlin/io/github/typesafegithub/workflows/mavenbinding/MavenMetadataBuilding.kt

Line 23 in a5b842c

<artifactId>${name.replace("__", "/")}</artifactId>

but not sure what consequences it would have for parts that now work.

[Vampire]

That's known and will be fixed by #1608.
As a temporary work-around you could disable usage of Gradle Module Metadata for the repository in the consuming build until the fix is live.

[Vampire]

repositories {
    maven {
        ...
        metadataSources {
            ignoreGradleMetadataRedirection()
        }
    }
}

[mareklangiewicz]

repositories {
    maven {
        ...
        metadataSources {
            ignoreGradleMetadataRedirection()
        }
    }
}

@Vampire
This doesn't help. Still the same error:

      > Could not resolve gradle:actions__setup-gradle:v4.
         > inconsistent module metadata found. Descriptor: gradle:actions/setup-gradle:v4 Errors: bad module name: expected='actions__setup-gradle' found='actions/setup-gradle'

Maybe it's some kind of gradle safety feature checking the .pom artifactId or description or sth?
https://bindings.krzeminski.it/gradle/actions__setup-gradle/v4/actions__setup-gradle-v4.pom

[Vampire]

Ah, it is the pom, was tricked by "metadata". Then it is #1609 that will fix it. And the work-around is to disable pom usage for now using

repositories {
    maven {
        ...
        metadataSources {
            artifact()
        }
    }
}

[mareklangiewicz]

Ah, it is the pom, was tricked by "metadata". Then it is #1609 that will fix it. And the work-around is to disable pom usage for now using

repositories {
    maven {
        ...
        metadataSources {
            artifact()
        }
    }
}

That doesn't work either. From the stacktrace I can see that gradle probably keeps failing on this line:
https://github.com/gradle/gradle/blob/3a1f8427b9455b1d1620048a9a2c1f0a4f2b727b/platforms/software/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/metadata/AbstractRepositoryMetadataSource.java#L123

[Vampire]

Stop using mavenLocal(), it is broken-by-design in Maven already.
If you really really really need to use it, at least have it as last in the list of repositories and always with a repository content filter that defines what exactly should come from there.

[krzema12]

@Vampire sorry, I missed any mention of Maven Local. How is it related to this ticket?

Regarding the bug, I've just merged a nice refactoring from @Vampire that will help avoiding such bugs in the future. Next steps:

• add a reproducing test by adding a small Gradle module/project that consumes a top-level action and an action under some path. Call it from the GitHub workflow that starts the server locally
• rebase and merge fix(server): use correct coordinates in generated POM file #1609 plus other PRs related to fixing names in various metadata files

[Vampire]

sorry, I missed any mention of Maven Local. How is it related to this ticket?

It was implicit and coming from my gut feeling. :-D

My work-around does work, I tried it.
As it did not work it must come from a different repository.
One possibility is that the work-around was done on the wrong repository.
Another - much more likely - possibility is, that Maven Local is used as repository and that the broken POM is still read from there. :-)