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

[Metallist-dev]

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]

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]

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]

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]

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.

[damienpalacio]

noticed same issue on our side with:
dependency-submission@v4

[bigdaz]

@damienpalacio Can you confirm that you are using self-hosted runners? Can you provide any details of the environment?

[damienpalacio]

@bigdaz yes I confirm we use self-hosted runner like this:
runs-on: [ self-hosted, java-small ]

I know we are using https://github.com/actions/actions-runner-controller but I don't the details of the configuration