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

class cast from DependencyExtractorBuildService to DependencyExtractor failed on self-hosted runner #223

Open
Metallist-dev opened this issue May 11, 2024 · 4 comments

Comments

@Metallist-dev
Copy link

Hi,
I tried setting up the dependency-submission action on my public repo, but it failed due to a cast error like in #146 and #132 of the gradle plugin.
Since it still seems to be a bit unclear what causes this, I will try to provide as many information about my situation as possible. If there's more I can give, feel free to ask.

my environment

  • multi-module project
  • using JDK 17 and gradle 8.6
  • self-hosted runner on manjaro (release 23.1.4) virtual machine (KVM/QEMU)
  • using only in workflow, not as local plugin (see section of what I tried)
  • pretty much the standard workflow-yaml:
name: Dependency submissions
on:
  - pull_request

permissions:
  contents: write

jobs:
  dependency-submission:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: Generate and submit dependency graph
        uses: gradle/actions/dependency-submission@v3
        with:
          dependency-graph-continue-on-failure: true

What I expected
Well, a green check mark on the actions job and a list of dependencies on my repo for the dependabot. ^^

What I got

class org.gradle.dependencygraph.extractor.DependencyExtractorBuildService$Inject cannot be cast to class org.gradle.dependencygraph.extractor.DependencyExtractor (org.gradle.dependencygraph.extractor.DependencyExtractorBuildService$Inject is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader @16afcba6; org.gradle.dependencygraph.extractor.DependencyExtractor is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader @64f8f28c)

What I tried so far

  • I tried using a completely fresh GitHub runner (v2.136.1) -> no effect
  • I tried running it locally -> worked locally, but didn't quite meet my plan to keep the repo as clean as possible
  • I tried pinning the gradle version and working-root to the most important module. -> didn't work either

I at least hope contributing any insights on the underlying issue. Of course, if I can try anything else to resolve the issue, I would be more than happy to try it. :)
Please make me aware, if I missed a solution of this issue some where.

@bigdaz
Copy link
Member

bigdaz commented May 11, 2024

Thanks for your report. Is this issue reproducible? Does it occur on every execution, or just sporadically?

One thing that might help is having the full stacktrace to the exception.
Can you please try running with --stacktrace as an additional argument?

      - name: Generate and submit dependency graph
        uses: gradle/actions/dependency-submission@v3
        with:
          additional-arguments: '--stacktrace'

You should then be able to see the full stacktrace of the failure in the GitHub Actions logs.

@bigdaz
Copy link
Member

bigdaz commented May 11, 2024

Are you able to test this on a GitHub-hosted runner?
Do you have any other self-hosted runner images you can try it on?

@Metallist-dev
Copy link
Author

Thanks for your quick reply.

On my manjaro VM it occurred on every execution. Now I've tried the suggestions with the stacktrace-argument and the other self-hosted runner.

The stacktrace didn't seem to bring many new information, but I'll upload the log archive of the failed run for you, just in case it might help you.
logs_23683788825-failed-manjaro.zip

What made the difference, was the system. I've set up a fresh runner on my host system opensuse leap 15.5 and there it worked immediately.
I didn't manage to try a GitHub-hosted runner yet, but I will definitely try it out tomorrow.

Although I have some kind of a solution now, I can sure try other things, if that helps. Maybe the reason for all this can be found.

@Metallist-dev
Copy link
Author

Hi, sorry for the late reply, had some stuff keeping me from developing.

I just tried the GitHub-hosted runner "ubuntu-latest" and it also worked. So I assume there are some needed prerequisites, which some systems have and some don't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants