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

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

Closed
1 of 3 tasks
krzema12 opened this issue Oct 26, 2024 · 12 comments · Fixed by #1609
Closed
1 of 3 tasks

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

krzema12 opened this issue Oct 26, 2024 · 12 comments · Fixed by #1609
Labels
bug Something isn't working

Comments

@krzema12
Copy link
Member

krzema12 commented Oct 26, 2024

Component

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 krzema12 added the bug Something isn't working label Oct 26, 2024
@krzema12
Copy link
Member Author

Noticed by @mareklangiewicz.

@krzema12
Copy link
Member Author

I suspect we'd need to adjust

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

@Vampire
Copy link
Collaborator

Vampire commented Oct 26, 2024

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
Copy link
Collaborator

Vampire commented Oct 26, 2024

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

@mareklangiewicz
Copy link

mareklangiewicz commented Oct 26, 2024

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
Copy link
Collaborator

Vampire commented Oct 26, 2024

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
Copy link

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
Copy link
Collaborator

Vampire commented Oct 27, 2024

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
Copy link
Member Author

@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
Copy link
Collaborator

Vampire commented Oct 27, 2024

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. :-)

@krzema12
Copy link
Member Author

krzema12 commented Oct 27, 2024

@mareklangiewicz the issue should be gone, we now have this in the POM:

<artifactId>actions__setup-gradle</artifactId>

please confirm it works fine in your project!

Thanks @Vampire for your help 🙇

@mareklangiewicz
Copy link

Yes, that fixes it. Thanks @krzema12 and @Vampire !
Also @Vampire your gut feeling was right :) I had mavenLocalFootgun enabled :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants