For dependency submission action, why does the example in Integrating the dependency-review-action section requires a second job?

Looking at the implementation the submission is done immediately after the generation with the download-and-submit parameter and the complete step in setup-gradle action skips any action when the input is download-and-submit (src)

So this makes me conclude that example could be much simpler and not require a second job.

name: Dependency review for pull requests

on: [ pull_request ]

permissions:
  contents: write

jobs:
  dependency-submission:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout sources
      uses: actions/checkout@v4
    - name: Generate and submit dependency graph
      uses: gradle/actions/dependency-submission@v3
    - name: Perform dependency review
      uses: actions/dependency-review-action@v3

Did I miss something in my analysis?

We have CI workflows/jobs setup w/ the Gradle build action - it's running fine w/o any issues for quite a while now.

The only thing that I do not fully understand is that the build summary lists a lot of "phantom" Gradle builds that requested the classes task (see screenshot), although the workflow does not do that, neither do our build files directly.

We do use the Quarkus plugin in our builds, and I suspect that the Quarkus plugin somehow triggers/causes these "phantom" builds listed in the summary.

Would it be possible to hide these "phantom" builds in the action?

Workflow reference
"Heads-up" on the Quarkus side: quarkusio/quarkus#29890

Hello,

we have the same problem in our matrix Windows gradle cache build. The warning appears with every run. As a workaround we have removed the option "cache: gradle".

Please see also:

https://github.com/Dungeon-CampusMinden/Dungeon/blob/4a13e21111e6c0a62d4bb0dfc65e257885ded40c/.github/workflows/github_ci.yml#L22
Dungeon-CampusMinden/Dungeon#1354
Dungeon-CampusMinden/Dungeon#1438

relates to gradle/gradle-build-action#644

You could update the Gradle version in the properties but forget to update the wrapper too.

This could also be a (theoretically) security risk by checking-in a valid but outdated wrapper which could have vulnerabilities.

Hi! 👋

Our Gradle home cache is getting so big in our project that is taking long times loading and storing the cache, so we enabled the gradle-home-cache-cleanup flag to remove unused files from Gradle User Home before saving to the cache.

After enabling this flag, the home cache entry dropped from 3.6 GB to 2.3 GB. While this is an improvement, we expected more. If we remove all the caches in Github actions and we start a fresh new runner without any cache, it only generates 457 MB. Therefore it is still keeping 80% of data that was actually not used in the last build. Please note that I only refer to the Gradle User Home entry.

After doing some debugging in a sample project (by enabling logging and exploring the sectionGradle User Home (directories >5M): after extracting common artifacts) I observed that it keeps multiple transforms-x folders, which represent a big part of the contents stored in the home cache. In theory a certain version of Gradle should use a consistent X value for that folder, so most likely the cleanup is not properly removing these unused folders left behind after a Gradle bump.

This is an Android project, mostly Kotlin code. The cache was never cleaned up in the last 4 months. It started with Gradle 8.4, later we migrated to 8.5 and last week to 8.6.

I also observed the home increasing significantly when bumping some dependencies (please note that I do not refer to the dependencies entry, which is stored separately, but still talking about the home), but I didn't research this thoroughly. Most likely this could be the next step to explore after figuring out why the transforms folder is still there.

You can check the thread in the slack community for a few other details.

Thanks!

Our gradle action config looks as the following

    - name: Setup Gradle
      uses: gradle/[email protected]
      with:
        gradle-version: wrapper
        gradle-home-cache-cleanup: true
        cache-read-only: false

so assumption is that in post-action gradle will clean up cache in home directory thanks to gradle-home-cache-cleanup: true. Actually in Post Setup Gradle I see the following message

Post job cleanup.
In final post-action step, saving state and writing summary
Stopping all Gradle daemons before saving Gradle User Home state
Stopping Gradle daemons for /home/runner/.gradle/wrapper/dists/gradle-7.4.[2](https://github.com/pleo-io/triton/runs/8232662390?check_suite_focus=true#step:43:2)-bin/48ivgl02cpt2ed[3](https://github.com/pleo-io/triton/runs/8232662390?check_suite_focus=true#step:43:3)fh9dbalvx8/gradle-7.[4](https://github.com/pleo-io/triton/runs/8232662390?check_suite_focus=true#step:43:4).2
/home/runner/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8/gradle-7.4.2/bin/gradle --stop
Stopping Daemon(s)
1 Daemon stopped
Forcing cache cleanup.
Warning: Unhandled error in Gradle post-action - job will continue: Error: Unable to locate executable file: gradle. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
Error: Unable to locate executable file: gradle. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
    at Object.<anonymous> (/home/runner/work/_actions/gradle/gradle-build-action/v2.3.0/dist/webpack:/gradle-build-action/node_modules/@actions/io/lib/io.js:213:1)
    at Generator.next (<anonymous>)
    at fulfilled (/home/runner/work/_actions/gradle/gradle-build-action/v2.3.0/dist/webpack:/gradle-build-action/node_modules/@actions/io/lib/io.js:24:1)

based on sources https://github.com/gradle/gradle-build-action/blob/main/src/cache-cleaner.ts I see as if dummy gradle project does actual clean up. But from where this project should get gradle to execute this

        await exec.exec(`gradle -g ${this.gradleUserHome} --no-daemon --build-cache --no-scan --quiet noop`, [], {
            cwd: cleanupProjectDir
        })

?

Would you please clarify how to properly configure gradle-home-cache-cleanup so it would get gradle from somewhere. Thanks!

In a previous job run, a corrupt Gradle distribution got cached. Subsequent job executions fail since they use the corrupt cache entry.

Could not unzip /home/runner/.gradle/wrapper/dists/gradle-7.2-all/260hg96vuh6ex27h9vo47iv4d/gradle-7.2-all.zip to /home/runner/.gradle/wrapper/dists/gradle-7.2-all/260hg96vuh6ex27h9vo47iv4d.
Reason: invalid stored block lengths
Exception in thread "main" java.util.zip.ZipException: invalid stored block lengths
	at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:165)
	at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
	at org.gradle.wrapper.Install.copyInputStream(Install.java:266)
	at org.gradle.wrapper.Install.unzip(Install.java:252)
	at org.gradle.wrapper.Install.access$900(Install.java:27)
	at org.gradle.wrapper.Install$1.call(Install.java:81)
	at org.gradle.wrapper.Install$1.call(Install.java:48)
	at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
	at org.gradle.wrapper.Install.createDist(Install.java:48)
	at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
	at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:63)
Error: Gradle build failed: process exited with status 1

As a developer, I need a way to work around a corrupt cache entry, either by an option to ignore the cache to be able to rebuilt it or by ignoring it during a failed execution.

I have an existing workflow that is calling gradle-build-action@v2 and successfully builds and submits the dependency graph for my projects. Today I've tried upgrading that to the new dependency-submission action and couldn't get it to work.

Current action:

      - name: Run gradlew task to analyse the runtime dependencies
        uses: gradle/gradle-build-action@v2
        env:
          DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: runtimeClasspath
        with:
          gradle-version: "5.6"
          dependency-graph: generate-and-submit
          build-root-directory: .
          arguments: dependencies

New version which fails:

      - name: Run gradlew task to analyse the runtime dependencies
        uses: gradle/actions/dependency-submission@v3
        env:
          DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: runtimeClasspath
        with:
          gradle-version: "5.6"
          dependency-graph: generate-and-submit
          build-root-directory: .

The error I'm seeing during the build, like mentioned in the title, is:

(...)

Welcome to Gradle 5.6!

Here are the highlights of this release:
 - Incremental Groovy compilation
 - Groovy compile avoidance
 - Test fixtures for Java projects
 - Manage plugin versions via settings script

For more details see https://docs.gradle.org/5.6/release-notes.html


Unknown command-line option '--dependency-verification'.

USAGE: gradle [option...] [task...]

I've not been able to understand when that CLI option has been introduced, but it really does not seem to be there in version 5.6.

In gradle/gradle-build-action#933 the gradle configurations were enhanced to support a custom plugin repository provided by the user. These plugin repositories can require authentication but there is currently no mechanism to also provide a credentials block to this configuration.

It would be helpful if we could also provide a username and password to the custom plugin repository e.g.

  repositories {
    maven { 
      url "<private gradle plugin repository>
      credentials {
        username = System.getenv("USERNAME")
        password = System.getenv("PASSWORD")
      }
    }
  }

This may not be the correct spot to request this, so please let me know if not.

I have a requirement to use private GitHub Runners, I can't use the github-hosted runners. Also, my private runners are long-lived VMs that run many jobs over many weeks.

This results in a Gradle user home ~/.gradle getting cluttered up over time. Right now, I am manually cleaning this directory with a run step in my workflow. I'm also curious what other directories Gradle uses to store historical data or caches, that I should also be cleaning? Sorry, I'm fairly new to Gradle.

Has there been any thought to creating an action that could reset / clear all Gradle-related directories for a scenario such as mine? GitHub-hosted Runners do not have this issue because they offer a clean VM for every job.

Thanks in advance.

There isn't any significant changes, but it's confusing.

For a single build, it looks like some of the dependencies are captured twice with different versions

Reproduction

Run project/pipeline from oleg-nenashev/gradle-quarkus-plugin-demo@109b203

When Gradle execution fails it is quite possible that some required downloads and assets in the Gradle User Home will be incorrectly flagged as "unused" and removed during cache cleanup. This is particularly the case when the job fails early (like during configuration).

We should only run cache cleanup in the case where the build successfully runs to completion.

Gradle 8.6
JDK 17

I'm using the dependency-submission action and just used the simplest example.

name: Dependency Submission

on: [ push ]

permissions:
  contents: write

jobs:
  dependency-submission:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout sources
      uses: actions/checkout@v4
    - name: Generate and submit dependency graph
      uses: gradle/actions/dependency-submission@v3

However, its action is failing and can't execute gradlew which I never changed and IDE generated on project initialization. Here I'm providing links to the full raw pipeline error and my gradlew file.

2024-02-08T09:24:03.7482952Z ##[error]Error: Gradle script '/home/runner/work/freeDictionaryApp/freeDictionaryApp/gradlew' is not executable.
2024-02-08T09:24:03.7536635Z Error: Gradle script '/home/runner/work/freeDictionaryApp/freeDictionaryApp/gradlew' is not executable.
2024-02-08T09:24:03.7538765Z     at verifyIsExecutableScript (/home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140758:15)
2024-02-08T09:24:03.7541933Z     at validateGradleWrapper (/home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140744:5)
2024-02-08T09:24:03.7546118Z     at Object.gradleWrapperScript (/home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140737:5)
2024-02-08T09:24:03.7548440Z     at Object.<anonymous> (/home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140677:95)
2024-02-08T09:24:03.7549679Z     at Generator.next (<anonymous>)
2024-02-08T09:24:03.7551015Z     at /home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140667:71
2024-02-08T09:24:03.7552046Z     at new Promise (<anonymous>)
2024-02-08T09:24:03.7553530Z     at __webpack_modules__.23584.__awaiter (/home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140663:12)
2024-02-08T09:24:03.7555832Z     at Object.executeGradleBuild (/home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:140676:12)
2024-02-08T09:24:03.7556935Z     at /home/runner/work/_actions/gradle/actions/v3.0.0/dist/setup-gradle/main/index.js:141589:33

Hi 👋 Thanks for saving our build times ❤️ Would it make sense to include gradle-home-cache-cleanup: true by default and have the option opt-out? Sounds like this would be a reasonable default to expect?

When using gradle/actions/dependency-submission (or setup-gradle with dependency-graph enabled), a failing build can generate an empty or partial dependency graph. When this graph is submitted, it replaces the existing (correct) dependency graph, resolving any associated Dependabot Alerts.

We should only submit a dependency-graph when the generating build completes successfully.

Currently, we recommend that users configure a separate workflow running the wrapper-validation-action to verify that the Gradle wrapper jar is not corrupted.

Doing this automatically for any workflow using setup-gradle and dependency-submission would increase coverage of wrapper validation and reduce the complexity for users adopting Gradle with GitHub actions. The functionality already exists with the validate-wrappers parameter: this issue is about enabling this by default.

Issues outstanding to allow this:

• #281
• #172

With improved cache-cleanup configurability in Gradle 8 and further improvements in Gradle 8.8, we should simplify the code used to force the cleanup of all unused entries.

This will tie the cache-cleanup implementation to Gradle 8.8+, and we'll need to ensure that Gradle 8.8 is always used when running the cache-cleanup action. Provisioning the Gradle version to use for cache-cleanup will also address #33.

Hello dear Gradle community,

We faced a problem when working with the gradle/actions/dependency-submission@v3 when trying to filter the dependencies send to the submission API. In our workflow we called the action in combination with the DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS in order to filter all dependencies which are linked to test configurations. Unfortunately, the exclude mechanismn using the variable did not work as expected. The different dependencies which only exist in test(Runtime|Compile)Classpath and others were not filtered. We tried using different regex options in order to make sure our regex was not the problem.

However, using the include environment variable by defining DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[Ii]mplementation.*|[Rr]untime.*|[Cc]ompile.*|[Aa]pi.*|[Aa]nnotation.*' everything works fine.

Therefore, we wanted to ask, if this is a known issue. We already took a look at the source code processing the parameters in the dependency-submission but were not able to locate the problem. Maybe you could help us? As I've already mentioned include works as expected, but it would be easier to exclude the test related configurations instead.

Our workflow looks like the following:

1. Setting up Java 17 using actions/setup-java@v4
2. Check out repository using actions/checkout@v4
3. Calling the dependency-submission action as listed below:

     - name: Generate and save dependency graph
        uses: gradle/actions/dependency-submission@v3
        with:
          dependency-graph: generate-and-submit
          gradle-version: 8.6
        env:
          # Exclude dependencies that are only resolved in test classpaths
          DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[Ii]mplementation.*|[Rr]untime.*|[Cc]ompile.*|[Aa]pi.*|[Aa]nnotation.*'

If you want to rerun a failed job, you can optionally enable the debug mode.

This mode adds the environment variable ACTIONS_RUNNER_DEBUG to true, but this has no effect to the Gradle output.
Instead, you need to change your workflow file and add ./gradle build --debug manually.

Expectation:
Automatically add --debug/--info (and maybe --stacktrace) when ACTIONS_RUNNER_DEBUG is true without the need to manually change the workflow files.

It can be difficult to determine the root cause the results in a particular dependency version being included in the dependency-graph. Different versions can be configured for different subprojects and configurations, so resolving a Dependabot Alert is not always straightforward.

The easiest way to identify the root source of a dependency is via a Build Scan®, but when this isn't available it should be possible to get this information via logging together with the built-in dependency reporting of Gradle.

When setting gradle-home-cache-cleanup: true, the action will attempt to remove all unused files from Gradle User Home before saving the state.
When running a build with state loaded from the configuration-cache, many files in Gradle User Home (eg dependency jars) are not necessarily recorded as being used during the build.

Taken together, this means that after a successful build with configuration-cache reuse, the saved Gradle User Home will have no dependencies. This can result in a ClassNotFoundException failure in subsequent builds.

This is a prerequisite for using the action in any repository that makes use of nightlies.

This is a prerequisite for dogfooding in the gradle org which makes heavy use of nightlies.

Currently, the action consumes https://services.gradle.org/versions/all which contains information about the latest nightly and the latest release nightly only. All other nightlies are missing.

There is now an API that permits users to delete specific cache entries. It might be possible to leverage this to overwrite existing cache entries, allowing corrupted cache entries to be removed.

Two things we could do without user input:

• When running with cache-write-only, we could automatically delete any existing cache entries. This would have the effect of overwriting existing cache entries with the same key.
• If a cache entry is obviously corrupted (ie cannot be restored) we could delete it.

Validate gradle/wrapper/gradle-wrapper.properties:

1. Assume distributionUrl points to a canonical Gradle location. If the link is not listed in https://services.gradle.org/versions/all, then fail the validation.
2. For those who want a customized Gradle distribution, add skip-distribution-validation: true|false configuration option (default: false)
3. Enforce the valid distributionSha256Sum for the official distributions

Hi!

Just tried out Gradle 8.6 with gradle/actions/setup-gradle@v3 and it seems like a build-conventions (https://docs.gradle.org/current/samples/sample_sharing_convention_plugins_with_build_logic.html) related task input change is preventing my configuration-cache from being reused.
They do seem to cache fine on local builds.

Calculating task graph as configuration cache cannot be reused because 
an input to task ':build-conventions:generatePluginAdapters' has changed.

Sample job that I run:

- name: Run ktlint
  uses: gradle/actions/setup-gradle@v3
  with:
    gradle-home-cache-cleanup: true
    cache-encryption-key: ${{ secrets.GRADLE_CACHE_ENCRYPTION_KEY }}
    arguments: ktlintCheck

Is there any chance this might be related to gradle-home-cache-cleanup #19 ?
If not, is there anything else that we should cache?

I suppose build conventions falls under this category:

caches/<version>/kotlin-dsl and caches/<version>/scripts: These are the compiled build scripts. The Kotlin ones in particular can benefit from caching.

If this action is run and a user forgets to add the - uses: actions/checkout@v2 they get this uninformative error:

Run gradle/wrapper-validation-action@v1
  with:
    wrapper-directory: gradle/wrapper
    gradle-executable: gradlew
    allow-snapshots: true
    min-wrapper-count: 1
##[error]Gradle Wrapper Validation Failed!
  See https://github.com/gradle/wrapper-validation-action#reporting-failures
✗ Other validation errors:
  Expected to find at least 1 Gradle Wrapper JARs but got only 0

We should provide a more useful error when the GitHub action is running in the context of no files at all so that there is a more actionable step that users can take.

In Gradle 8.6, 8.7 and 8.8, some of the storage paths in Gradle User home are changed.

• In Gradle 8.6, Jar instrumentation is done via artifact transforms, so instrumented jars are now stored in cache/transforms-4 instead of cache/jars-9.
• In Gradle 8.7, compiled groovy scripts will end up in caches/<gradle-version>/groovy-dsl
• In Gradle 8.8, artifact transform outputs will be located in caches/<gradle-version>/transforms

We should update the extracted cache entry definitions based on these changes.

At the same time, it may be useful to extract separate "bundles" for caches/8.6/kotlin-dsl and caches/8.7/kotlin-dsl (as well as any other Gradle-version-bound caches that are extracted).

It seems Gradle is working about Problems API.
And these APIs contains problem events where errors are from.

So, if these APIs can integrated with Github Actions, developers can easily understand where compilation issues are coming from.

See gradle/github-dependency-graph-gradle-plugin#109.

Feature request

We are using the Gradle Build Action for our projects and it works great.
However, we are also interested in switching to BuildJet for better build agents.
They also provide faster cache services than GH Cache (link).

Hence the feature request -- allow different cache providers to be used with Gradle Build Action instead of always assuming the action will be using Github Action's Cache

Other forks

It looks like some people tried to create a fork of gradle-build-action and make it use BuildJet, but it's outdated.
So there seems to be an interest for this feature.

• https://github.com/marketplace/actions/gradle-buildjet-action

The distributionPath property in gradle/wrapper/gradle-wrapper.properties is not used when caching distributions. It appears that caching is only supported for the default wrapper/dists location.

At the moment, these actions are incompatible, and adding a dependency-submission step after setup-gradle will fail.

It should be possible to combine these actions in the same Job.

See #14

I saw that gradle/gradle-build-action@v2 recommends migrating to gradle/actions/setup-gradle instead. They both have caching, but the first run after changing from the old solution to this one does not have any cache:

Run gradle/actions/setup-gradle@v3
  with:
    gradle-home-cache-cleanup: true
    dependency-graph: generate-and-submit
    cache-disabled: false
    cache-read-only: false
    cache-write-only: false
    cache-overwrite-existing: false
    gradle-home-cache-includes: caches
  notifications
  
    add-job-summary: always
    add-job-summary-as-pr-comment: never
    dependency-graph-continue-on-failure: true
    build-scan-publish: false
    generate-job-summary: true
    gradle-home-cache-strict-match: false
    workflow-job-context: null
    github-token: ***
  env:
    ...
  
Merged default JDK locations into /home/runner/.m2/toolchains.xml
Restore Gradle state from cache
  Gradle User Home cache not found. Will initialize empty.
Preparing cache for cleanup.
Enabling dependency graph generation

I am assuming there are going to be a lot of people migrating over to this action, so being able to read the old cache if no new cache has been created yet would save a lot of CI minutes.

When a Job is cancelled, it may result in Gradle User Home being in an incomplete or inconsistent state. In this case, it's safer not to save the Gradle User Home to the GitHub Actions cache.

Hi there!

We've started getting build failures with this message since updating to gradle 8.6 while using this action:

Execution failed for task ':AnkiDroid:testPlayDebugUnitTest'.
> A build operation failed.
      Immutable workspace contents have been modified: /home/runner/.gradle/caches/transforms-4/f46cf63d0a549c8bc814e25133f449eb. These workspace directories are not supposed to be modified once they are created. Deleting the directory in question can allow the content to be recreated.
   > Immutable workspace contents have been modified: /home/runner/.gradle/caches/transforms-4/f46cf63d0a549c8bc814e25133f449eb. These workspace directories are not supposed to be modified once they are created. Deleting the directory in question can allow the content to be recreated.

Here's a sample run: https://github.com/ankidroid/Anki-Android/actions/runs/7932349193/job/21658645926?pr=15520

It reproduced originally in windows runners, and on a hunch it was windows file locking I disabled caching there and it worked

Now it is reproducing on ubuntu runners as well so I suppose it is an incompatibility?

Unfortunately it is persistent across runs - once whatever the incompatibility is triggers, the cache is saved with the problem latent in it, and any future runs that restore that gradle cache will fail with the error above.

This never happened prior to updating our gradle from 8.5 to 8.6 so perhaps that is the source of the incompatibility?

GitHub Actions/Cache supports enableCrossOsArchive to reuse the same cache from different operating systems. This is very handy for matrix builds using multiple OS to further reduce the CI time (and costs).

https://github.com/actions/cache/blob/main/tips-and-workarounds.md#cross-os-cache

The current Job Summary, while working OK, doesn't render well in some cases with long values.

1. The 'requested tasks' column includes all task options, which can make that column very wide.

Root Project	Requested Tasks	Gradle Version	Build Outcome	Build Scan™
dummy-project	wrapper --gradle-version 7.4.2 --gradle-distribution-sha256-sum 29e49b10984e585d8118b7d0bc452f944e386458df27371b49b4ac1dec4b7fda	7.4.2	✅

2. Similar to 2) a very long root project name or gradle task name will blow out the column width:

Root Project	Requested Tasks	Gradle Version	Build Outcome	Build Scan™
aVeryVeryVeryVeryVeryVeryVeryVeryRootProjectName	aVeryVeryVeryVeryVeryVeryVeryVeryLongTaskName	7.4.2	✅

3. In cases 2&3 above, the build scan badge is compressed making it unreadable.

The current version of undici being used is being flagged for this vulnerability:

see https://github.com/gradle/actions/blob/main/sources/package-lock.json#L8737

and GHSA-9f24-jqhm-jfcw

In addition to know that a wrapper JAR successfully validated, it would also be nice to see in the console output which version was actually found to be a match.

Also validate gradlew and gradlew.bat scripts.
These are not blobs so it is harder to overlook something, but I think these should be checked too.

Hello,

When tests fail in CI, here's what I get:

* What went wrong:
Execution failed for task ':module:allTests'.
> There were failing tests. See the report at: file:///home/runner/work/user/project/module/build/reports/tests/allTests/index.html

This is so unhelpful as the runner deletes everything on exit, and you won't find the test failure report in the Gradle scan…

Can you extract the containing directory as a downloadable GitHub Action run artifact if it has files, so that we can actually find out why the tests failed in CI?

I find it hard to believe that I'd be the first one encountering this issue, but I'll accept the truth.

Thank you and have a great day!

Louis CAD

Hello, I am trying to use the following steps in my GitHub Workflow. This is all I'm doing, yet I'm getting an error:

- uses: actions/checkout@v4
- name: Submit Dependencies
  env:
    GITHUB_JOB_CORRELATOR: '${{ github.workflow }}-${{ github.job }}'
    GITHUB_JOB_ID: '${{ github.run_id }}'
  uses: gradle/actions/dependency-submission@v3
  with:
    dependency-graph: 'generate-and-submit'

When running this I get the following error:

* What went wrong:
Cannot add task 'ForceDependencyResolutionPlugin_resolveAllDependencies' as a task with that name already exists.

Currently, there are 3 mechanisms by which Gradle distributions may be downloaded:

1. When the gradle-build-action provisions a specified Gradle version for use
2. When the Gradle wrapper is used to run a project
3. When Gradle TestKit is used to test a project with different Gradle versions.

Ideally, these would all share a common download location and cache entry, avoiding the need to re-download the same Gradle distribution multiple times.

In addition, if a Gradle distribution is pre-installed on the runner, it would be good if this version didn't have to be re-downloaded for the 3 mechanisms listed above.

When using add-job-summary-as-pr-comment it is sometimes simpler to open the GitHub job details pages.

Would it be possible to add such link: https://github.com/<user>/<project>/actions/runs/<run_id>/job/<job_id>?pr=<pr> in the summary?

It could for instance be a link behind the renderOutcome(result) emoji:

I'm trying to get dependency submission to work through the PR yonadev/yona-server#1289, but it fails with this error:

FAILURE: Build failed with an exception.

* What went wrong:
Task 'ForceDependencyResolutionPlugin_resolveAllDependencies' not found in root project 'yona-server'.

The dependency submission task is defined as follows:

      - name: Publish Gradle dependencies
        uses: gradle/actions/dependency-submission@v3
        with:
          build-root-directory: yona-server

The action to build the project is successful and is defined straight before the dependency submission. That looks as follows:

      - name: Build and analyze
        uses: gradle/actions/setup-gradle@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          build-root-directory: yona-server
          add-job-summary-as-pr-comment: on-failure
          arguments: |
            check
            sonarqube
            --info

We are running Gradle 7.5.1

Your help is appreciated!

In the same way this action hooks on the Gradle build to gather details about the project being run and further caching what is getting downloaded, it would be nice to have the same behavior for the Android plugin.

Currenly we are caching the whole Andrioid SDK folder (after starting with just the command line tools installed and letting AGP download what it needs). But this approach may eventually grow indefinitely by having platform-sdk for instance no longer used by any Android build.

Probably this is not strictly in scope of this action but I can imagine the behavior and implementation will be pretty much the same: hook on the build, react on AGP plugin, and cache those SDKs components used by the build.

Caused by: org.gradle.internal.exceptions.DefaultMultiCauseException: The dependency-graph extractor plugin encountered errors while extracting dependencies. Please report this issue at: https://github.com/gradle/github-dependency-graph-gradle-plugin/issues
	at org.gradle.dependencygraph.extractor.DependencyExtractor.close(DependencyExtractor.kt:296)
	at org.gradle.api.services.internal.RegisteredBuildServiceProvider.lambda$maybeStop$1(RegisteredBuildServiceProvider.java:168)
	... 133 more
Caused by: java.lang.IllegalStateException: buildOperation.details & finishedEvent.result were unexpected types
	at org.gradle.dependencygraph.extractor.DependencyExtractor.finished(DependencyExtractor.kt:337)
	at org.gradle.internal.build.event.DefaultBuildEventsListenerRegistry$ForwardingBuildOperationListener.handle(DefaultBuildEventsListenerRegistry.java:234)
	at org.gradle.internal.build.event.DefaultBuildEventsListenerRegistry$ForwardingBuildOperationListener.handle(DefaultBuildEventsListenerRegistry.java:211)
	at org.gradle.internal.build.event.DefaultBuildEventsListenerRegistry$AbstractListener.run(DefaultBuildEventsListenerRegistry.java:180)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	... 5 more

https://github.com/ben-manes/caffeine/actions/runs/8033070787/job/21943169140