gradle/actions

A collection of GitHub Actions to accelerate your Gradle Builds on GitHub

GitHub Actions for Gradle builds

This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.

The setup-gradle action

The setup-gradle action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.

This replaces the previous gradle/gradle-build-action, which now delegates to this implementation.

The recommended way to execute any Gradle build is with the help of the Gradle Wrapper, and the examples assume that the Gradle Wrapper has been configured for the project. See this example if your project doesn't use the Gradle Wrapper.

Example usage

name: Build

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout sources
      uses: actions/checkout@v4
    - name: Setup Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: 17
    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@v3
    - name: Build with Gradle
      run: ./gradlew build

See the full action documentation for more advanced usage scenarios.

The dependency-submission action

Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.

The following workflow will generate a dependency graph for a Gradle project and submit it immediately to the repository via the Dependency Submission API. For most projects, this default configuration should be all that you need.

Simply add this as a new workflow file to your repository (eg .github/workflows/dependency-submission.yml).

name: Dependency Submission

on:
  push:
    branches: [ 'main' ]

permissions:
  contents: write

jobs:
  dependency-submission:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout sources
      uses: actions/checkout@v4
    - name: Setup Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: 17
    - name: Generate and submit dependency graph
      uses: gradle/actions/dependency-submission@v3

See the full action documentation for more advanced usage scenarios.

The wrapper-validation action

The wrapper-validation action validates the checksums of all Gradle Wrapper JAR files present in the repository and fails if any unknown Gradle Wrapper JAR files are found.

The action should be run in the root of the repository, as it will recursively search for any files named gradle-wrapper.jar.

Example workflow

name: "Validate Gradle Wrapper"

on:
  push:
  pull_request:

jobs:
  validation:
    name: "Validation"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: gradle/actions/wrapper-validation@v3

See the full action documentation for more advanced usage scenarios.

actions's Issues

Create FAQ regarding `dependency-submission`

When people use gradle/actions/dependency-submission for the first time, they have a lot of questions. We should attempt to provide answers in a FAQ.

Here's a start:

Q. How can I tell if the dependency-submission action is working?
A. Inspect the Dependency Graph for your project (Insights -> Dependency Graph). You should see some dependencies annotated with "Detected by GitHub Dependency Graph Gradle Plugin"

Q. Why is "(Maven)" stated for all dependencies submitted by this action? I'm not using Maven.
A. This simply indicates that the dependency was resolved from a standard Gradle/Maven artifact repository. It does not imply which build tool is used.

Q. Why is every dependency attributed to settings.gradle.kts? All of my dependencies versions are declared in build.gradle / libs.versions.toml / version.properties.
A. The attribution of all dependencies to the root settings file is due to a limitation in the GitHub Dependency Graph, which was modelled heavily on NPM and doesn't really map well to how Gradle projects declare and resolve dependencies.
It is not possible for the dependency-submission action to accurately map each dependency version to a specific "manifest file" for 2 reasons:

• The Gradle events that are received when resolving dependencies don't contain this information. It may be possible (but difficult), to develop a plugin that extracts this information.
• The GitHub Dependency Submission API is not suitable for the Gradle model where: a) the same dependency can be declared and consumed in many build files and b) many files (including plugins) can contribute logic used to determine dependency versions.

We have long-term plans to improve the first point, and we are working with GitHub to resolve the second. However, at this stage the behaviour your are experiencing is what is expected.

Q. The dependency graph contains a dependency that isn't anywhere in my build. Why is the action reporting dependencies I'm not using?
A. If you see a particular dependency version in the dependency graph, this means your build is resolving that dependency at some point. You might be surprised what transitive dependencies are brought in by declared dependencies, including applied plugins.
See here for a HOW-TO on getting the bottom of why the dependency is being resolved.

Q. I see multiple versions of the same dependency in the dependency graph, but I'm only declaring a single version in my build. Why is the action reporting dependency versions I'm not using?
A. This is almost certainly because the dependency in question is actually being resolved with different versions in different dependency configurations. For example, you may have one version brought in as a plugin dependency (resolved in the classpath configuration) and another used directly as a code dependency (resolved in the compileClasspath configuration).
See here for a HOW-TO on getting the bottom of why the dependency is being resolved. By far the easiest way is to publish a Build Scan® for the workflow run: this is easily achieved with some additional action configuration.

Q. I'm not seeing any security vulnerabilities for any of my dependencies. How can I be sure this is working?
A. First check that Dependabot Alerts are enabled for your repository. Without this, your dependency graph may be populated but you won't see which dependencies are potentially vulnerable.

Q. How can I use Dependabot Security Updates to generate a PR to update my vulnerable dependencies?
A. In most cases, Dependabot Security Updates is not able to automatically generate a PR to update a dependency version. This can be due to the vulnerable dependency being transitive (and so there's nowhere to update the version), or because the Dependabot implementation doesn't understand how to update the version.
In a few select cases the Dependabot security update will work and generate a PR. eg when a direct dependency version is listed in a TOML dependency catalog.

Q. I'm getting many false positive Dependabot Alerts for dependencies that aren't used by my project. Why are these dependencies being reported?
A. The dependency-submission action resolves all of the dependencies in your build. This includes plugins, dependencies you've declared, test dependencies, and all transitive dependencies of these. It doesn't matter how the dependencies are declared: the ones being resolved by Gradle are the ones being reported.

Many people are surprised to see what dependencies are actually being resolved when they run their builds, but I'm yet to see a case where the dependencies being reported are actually incorrect. If you can confirm that a dependency is really being reported and not resolved by your project, then I can investigate further.

Please follow the instructions here to identify the source of the dependency version that is being reported.

Once you have worked out why it is being resolved, you can either update the dependency version or exclude it from the submitted dependency graph.

Problems with exclude of configurations in dependency-submission@v3

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.*'

Job summary lists unwanted results for builds invoked by tooling and/or tests

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

⏳ Long setup on Windows

Using gradle/actions/[email protected], the setup of Gradle takes more than 5 minutes on Windows.
Here's an example of a job in GitHub Action that took 10m 43s, including 7m 10s just for using this action.

Investigate using https://github.com/nektos/act to run workflow tests locally

Clearing Gradle caches on self-hosted runners

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.

Allow `setup-gradle` and `dependency-submission` to be used in the same Job

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

Build (windows-latest): `Failed to save: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2`

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

Automatically perform wrapper validation check in `setup-gradle`

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 would increase coverage of wrapper validation and reduce the complexity for users adopting Gradle with GitHub actions.

We could also leverage the wrapper-check to avoid executing an invalid wrapper jar in dependency-submission

Gradle User Home should not be saved for cancelled Jobs

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.

Report source of dependency in dependency-graph via debug logging

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.

Incomplete dependency-graph is submitted on build failure

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.

Extract test results when there are failures

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

Support ACTIONS_RUNNER_DEBUG mode

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.

Improving `gradle-home-cache-cleanup` detection of unused files

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!

Allow cache-write-only to overwrite existing cache entries

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.

Cache cleanup is incompatible with configuration-cache reuse

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.

Dependency Graph submission should be reported in Job Summary

Make it possible to use `@buildjet/cache` library as a replacement for `@actions/cache`

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

Upgrade `undici`

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

Support authentication for plugin repositories

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")
      }
    }
  }

dependency submission Integrating the dependency-review-action example doesn't seem to require a second job

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?

v3 tag still points to RC 2

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

Honor custom distributionPath for caching downloaded wrapper distributions

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.

Allow action, wrapper and testKit to share downloaded Gradle distributions

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.

Dependency submission fails when project isolation is enabled

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

Capture task input files when plugin is not applied

The current task input file capturing implementation sets the parameter for cases when the plugin may or may not already be applied. It would also override the existing setting even if the corresponding environment variable isn't set.

As an improvement, we can tweak the implementation to do the following:

1. Set the value only when the corresponding environment variable is explicitly specified.
2. Only set it for cases where a project doesn't already have the Develocity Gradle Plugin applied. This would preserve the behavior specified in the user's build script.

Included builds containing build logic prevent configuration-cache reuse

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.

Cache cleanup should not run for cancelled or failed jobs

If the Job execution is failed or cancelled, then 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.

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

Provide a mechanism to deal with a corrupted cache entry

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.

Task exists error with Dependency-Submission action

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.

Some dependencies seem to be captured twice

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

Environment variables defined in `toolchains.xml` are incorrect on ARM runners

The toolchain.xml contains x86 env variables which aren't guaranteed to exist on arm, like macOS-14 (M1) or Ubuntu Arm runners (currently in private Beta), or on any custom hosted runner:

<!-- JDK Toolchains installed by default on GitHub-hosted runners -->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>8</version>
      <vendor>Eclipse Temurin</vendor>
    </provides>
    <configuration>
      <jdkHome>${env.JAVA_HOME_8_X64}</jdkHome>
    </configuration>
  </toolchain>

When using Gradle, this results into these warnings on macOS-14 (M1)/Ubuntu Arm:

Directory '/home/runner/.gradle/daemon/8.7-rc-3/${env.JAVA_HOME_8_X64}' (Maven Toolchains) used for java installations does not exist
Directory '/home/runner/.gradle/daemon/8.7-rc-3/${env.JAVA_HOME_21_X64}' (Maven Toolchains) used for java installations does not exist
Directory '/home/runner/.gradle/daemon/8.7-rc-3/${env.JAVA_HOME_11_X64}' (Maven Toolchains) used for java installations does not exist
Directory '/home/runner/.gradle/daemon/8.7-rc-3/${env.JAVA_HOME_17_X64}' (Maven Toolchains) used for java installations does not exist

After using setup-java with 21, on Ubuntu Arm there is only one env: JAVA_HOME_21_ARM64=/home/runner/work/_tool/Java_Adopt_jdk/21.0.2-13.0.LTS/arm64

Import cache from gradle/gradle-build-action@v2

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.

Add support for granular cache on Android SDK

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.

Attempt to simplify Gradle User Home cleanup with Gradle 8

With improved cache-cleanup configurability in Gradle 8, we may be able to simplify the code used to force the cleanup of all unused entries. Investigate.

Cache paths require updating for Gradle 8.6+

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

Unknown command-line option '--dependency-verification' with Gradle 5.6

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.

Feature Request: add inline comment for compilation errors by Problem APIs.

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.

setup-gradle: ./gradlew: No such file or directory

I see a critial error in my first try using setup-gradle

./gradlew: No such file or directory

The error scenario and logs sits in
https://github.com/davidkhala/java-common/actions/runs/8387290539/job/22969204674

Please let me know if it is known issue.

[dependency-submission] Gradle 8.7-rc-1 incompatibility

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

Allow cache entries to be reused on different runner operating systems

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

Question (issue?) about Dependency Submission and GitHub Dependabot

Can you tell me if this is how things are supposed to work?

I have a Gradle project hosted in a GitHub repo. I have a simple GitHub workflow that runs a standard ./gradlew build and also uses the dependency-submission action. My project has a build.gradle file with quite a few things listed directly under dependencies{}.

I would like to make use of GitHub Dependabot Security Updates. This should automatically open PRs for any dependencies that have vulnerabilities. However, when I look at my repo's dependencies, (which were created and uploaded by the action), then I only see transitive dependencies, which all show as coming from the settings.gradle file.

I should be seeing my direct dependencies coming from my build.gradle file, right? Since these are showing as indirect, and from settings.gradle then Dependabot Security Updates can't create an automatic PR for them: This is an indirect dependency not explicitly present in any manifest file, so Dependabot cannot update it.

Is there anything I can do about this?

Cache cleanup fails with "Unable to locate executable file: gradle" when Gradle is not pre-installed on runner

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!

Dependency submission action should handle non-executable `gradlew` script

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

Provide link to GitHub job in generated PR comment

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:

actions/sources/src/job-summary.ts

Lines 94 to 103 in 7fda81f

	function renderBuildResultRow(result: BuildResult): string {
	return `
	<tr>
	<td>${result.rootProjectName}</td>
	<td>${result.requestedTasks}</td>
	<td align='center'>${result.gradleVersion}</td>
	<td align='center'>${renderOutcome(result)}</td>
	<td>${renderBuildScan(result)}</td>
	</tr>`
	}

Make gradle-home-cache-cleanup: true the default

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?

Improve rendering of build results table with long values

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.

Fail nicely if `dependency-submission` and `setup-gradle` are used together in the same Job

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!

Immutable workspace contents have been modified with current gradle (8.6) and this action

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?