Running different tasks results into different dependency graphs

[hfhbd]

I run the following Gradle tasks: build and detekt, so I get 3 dependency graphs (build, detekt, cleanup). These files differs:

• They have different artifacts, the 2nd run (detekt) misses many artifacts.
• Some artifacts are marked as direct in the first graph, but indirect in the second run.
• The cleanup graph is empty.

AFAIK GitHub uses the latest one (same correlator, higher timestamp) as final results, resulting in less dependencies.

Results: https://github.com/hfhbd/ComposeTodo/suites/15996628865/artifacts/913210709

CI run: https://github.com/hfhbd/ComposeTodo/actions/runs/6133473569/job/16645352703

CI config:

name: CI

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: macos-latest
    permissions:
      contents: write
      security-events: write

    env:
      GRADLE_OPTS: -Dorg.gradle.caching=true

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v3
        with:
          distribution: 'adopt'
          java-version: 17
      - uses: gradle/gradle-build-action@v2
        with:
          dependency-graph: generate-and-submit
          gradle-home-cache-cleanup: true
      - uses: actions/cache@v3
        with:
          key: ${{ runner.os }}-kotlin-1.9.10
          path:
            ~/.konan
      - name: Build with Gradle
        run: ./gradlew build

      - name: Detekt
        run: ./gradlew detekt
        if: always()

[bigdaz]

Thanks for the report. Different dependency graphs for different Gradle task executions is expected: this represents the actual dependencies resolved during the build.

However, each of these graphs should have a different correlator, which should correspond to the graph file name ci-build, ci-build-1, etc. For some reason that's not working in your case and this is a bug. I'll investigate.

[bigdaz]

This is working as expected in the automated tests:

• Workflow job running multiple Gradle builds and generating dependency graphs: https://github.com/gradle/gradle-build-action/actions/runs/6263195722/job/17007059454
• Dependency graph results: https://github.com/gradle/gradle-build-action/suites/16415720636/artifacts/937953156

If you compare ci-full-check-multiple-builds.json and ci-full-check-multiple-builds-1.json, you'll see that the correlator value is different in each. This is done in the init-script, by setting a GITHUB_JOB_SUMMARY system property to match the output file name. In your case, the output file name is being set, but the system property doesn't seem to be heeded.

Can you please run a test to print out the values of System.env.GITHUB_JOB_SUMMARY and System.getProperty('GITHUB_JOB_SUMMARY') in your build script? The env var should always be ci-build but the system property should have the unique suffix. That could help narrow down where the problem is occurring (in the init-script that writes the property, or in the plugin that reads it).

[hfhbd]

Hey, after analyzing the ci-build files again, I think there is no problem: all files have different names and different CI aggregators, so this looks good.

But they still produce different scopes for the same dependencies depending on the executed tasks: direct and indirect.

I have no idea which dependencies are shown in the web view, if ever.

[bigdaz]

Thanks for confirming.

But they still produce different scopes for the same dependencies depending on the executed tasks: direct and indirect.

This is quite possible: a dependency that is used as a direct dependency for one execution could still be used as an indirect dependency in a different execution. Do you have build scans for the 2 different executions (this should provide an explanation of what's going on).

By the way when inspecting your project I discovered a separate issue with Dependency Submission.