Execute your Gradle build and trigger dependency submission
Find a file
Daz DeBoer 4ebd000afd
Bundle all downloaded dependency files
Previously, only .jar files were bundled, with other files (modules, POMs, zips, etc)
being left in Gradle User Home. All downloaded files are now included in the bundle.

Fixes #100
2021-10-29 08:03:03 -06:00
.github/workflows Bundle all downloaded dependency files 2021-10-29 08:03:03 -06:00
__tests__ Test execution with older Gradle versions 2021-09-29 13:34:05 -06:00
dist Build outputs 2021-10-27 16:09:53 -06:00
src Bundle all downloaded dependency files 2021-10-29 08:03:03 -06:00
.eslintignore Add various js build configs 2020-06-13 12:46:29 +02:00
.eslintrc.json Make file hashing more robust 2020-06-15 14:09:44 +02:00
.gitignore Ignore .tool-versions directory 2021-07-20 11:20:21 -06:00
.prettierignore Add various js build configs 2020-06-13 12:46:29 +02:00
.prettierrc.json Allow source files to contain lines up to 120 characters 2021-10-29 07:50:06 -06:00
action.yml Bundle all downloaded dependency files 2021-10-29 08:03:03 -06:00
CODE_OF_CONDUCT.md add code of conduct 2019-09-21 20:57:04 +02:00
jest.config.js Add various js build configs 2020-06-13 12:46:29 +02:00
jest.setup.js Add various js build configs 2020-06-13 12:46:29 +02:00
LICENSE Initial commit 2019-09-20 23:06:59 +02:00
package-lock.json Merge pull request #84 from gradle/dependabot/npm_and_yarn/ansi-regex-5.0.1 2021-09-28 08:45:48 -06:00
package.json Generate source-map files when compiling 2021-09-14 05:46:11 -06:00
README.md Use multiline input parameters instead of JSON input 2021-10-29 07:29:57 -06:00
tsconfig.json Split action, step 1 2020-06-13 13:30:20 +02:00

Execute Gradle builds in GitHub Actions workflows

This GitHub Action can be used to execute a Gradle build on any platform supported by GitHub Actions.

Usage

The following workflow will run ./gradlew build on ubuntu, macos and windows. The only prerequisite is to have Java installed: you define the version of Java you need to run the build using the actions/setup-java action.

# .github/workflows/gradle-build-pr.yml
name: Run Gradle on PRs
on: pull_request
jobs:
  gradle:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-java@v1
      with:
        java-version: 11
    - uses: gradle/gradle-build-action@v2
      with:
        arguments: build

It is possible to configure multiple Gradle executions to run sequentially in the same job. Each invocation will start its run with the filesystem state remaining from the previous execution.

- uses: gradle/gradle-build-action@v2
  with:
    arguments: assemble
- uses: gradle/gradle-build-action@v2
  with:
    arguments: check

Gradle Execution

Command-line arguments

The arguments input can used to pass arbitrary arguments to the gradle command line. Arguments can be supplied in a single line, or as a multi-line input.

Here are some valid examples:

arguments: build
arguments: check --scan
arguments: some arbitrary tasks
arguments: build -PgradleProperty=foo
arguments: |
    build
    --scan
    -PgradleProperty=foo
    -DsystemProperty=bar    

See gradle --help for more information.

If you need to pass environment variables, use the GitHub Actions workflow syntax:

- uses: gradle/gradle-build-action@v2
  env:
    CI: true
  with:
    arguments: build

Gradle build located in a subdirectory

By default, the action will execute Gradle in the root directory of your project. Use the build-root-directory input to target a Gradle build in a subdirectory.

- uses: gradle/gradle-build-action@v2
  with:
    build-root-directory: some/subdirectory

Using a specific Gradle executable

The action will first look for a Gradle wrapper script in the root directory of your project. If not found, gradle will be executed from the PATH. Use the gradle-executable input to execute using a specific Gradle installation.

 - uses: gradle/gradle-build-action@v2
   with:
     gradle-executable: /path/to/installed/gradle

This mechanism can also be used to target a Gradle wrapper script that is located in a non-default location.

Download, install and use a specific Gradle version

The gradle-build-action is able to download and install a specific Gradle version to execute.

 - uses: gradle/gradle-build-action@v2
   with:
     gradle-version: 6.5

gradle-version can be set to any valid Gradle version.

Moreover, you can use the following aliases:

Alias Selects
wrapper The Gradle wrapper's version (default, useful for matrix builds)
current The current stable release
release-candidate The current release candidate if any, otherwise fallback to current
nightly The latest nightly, fails if none.
release-nightly The latest release nightly, fails if none.

This can be handy to automatically verify your build works with the latest release candidate of Gradle:

# .github/workflows/test-gradle-rc.yml
name: Test latest Gradle RC
on:
  schedule:
    - cron: 0 0 * * * # daily
jobs:
  gradle-rc:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-java@v1
      with:
        java-version: 11
    - uses: gradle/gradle-build-action@v2
      with:
        gradle-version: release-candidate
        arguments: build --dry-run # just test build configuration

Caching

By default, this action aims to cache any and all reusable state that may be speed up a subsequent build invocation.

The state that is cached includes:

  • Any distributions downloaded to satisfy a gradle-version parameter ;
  • A subset of the Gradle User Home directory, including downloaded dependencies, wrapper distributions, and the local build cache ;
  • Any configuration-cache data stored in the project .gradle directory.

To reduce the space required for caching, this action makes a best effort to reduce duplication in cache entries.

Caching is enabled by default. You can disable caching for the action as follows:

cache-disabled: true

Cache keys

For cached distributions outside of Gradle User Home, the cache key is unique to the downloaded distribution. This will not change over time.

The state of the Gradle User Home and configuration-cache are highly dependent on the Gradle execution, so the cache key is composed of the current commit hash and the GitHub actions job id. As such, the cache key is likely to change on each subsequent run of GitHub actions. This allows the most recent state to always be available in the GitHub actions cache.

To reduce duplication between cache entries, certain artifacts are cached independently based on their identity. Artifacts that are cached independently include downloaded dependencies, downloaded wrapper distributions and generated Gradle API jars. For example, this means that all jobs executing a particular version of the Gradle wrapper will share common entries for wrapper distributions and for generated Gradle API jars.

Using the caches read-only

Cache storage space is limited for GitHub actions, and writing new cache entries can trigger the deletion of exising entries. In some circumstances, it makes sense for a Gradle invocation to read any existing cache entries but not to write changes back. For example, you may want to write cache entries for builds on your main branch, but not for any PR build invocations.

You can enable read-only caching for any of the caches as follows:

# Only write to the cache for builds on the 'main' branch.
# Builds on other branches will only read existing entries from the cache.
cache-read-only: ${{ github.ref != 'refs/heads/main' }}

Gradle User Home cache tuning

As well as any wrapper distributions, the action will attempt to save and restore the caches and notifications directories from Gradle User Home.

The contents to be cached can be fine tuned by including and excluding certain paths with Gradle User Home.

# Cache downloaded JDKs in addition to the default directories.
gradle-home-cache-includes: |
    caches
    notifications
    jdks    
# Exclude the local build-cache from the directories cached.
gradle-home-cache-excludes: |
    caches/build-cache-1    

You can specify any number of fixed paths or patterns to include or exclude. File pattern support is documented at https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#patterns-to-match-file-paths.

Cache debugging

It is possible to enable additional debug logging for cache operations. You do via the GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED environment variable:

env:
  GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true

Note that this setting will also prevent certain cache operations from running in parallel, further assisting with debugging.

Build scans

If your build publishes a build scan the gradle-build-action action will:

  • Add a notice with the link to the GitHub Actions user interface
  • Emit the link to the published build scan as an output named build-scan-url.

You can then use that link in subsequent actions of your workflow. For example:

# .github/workflows/gradle-build-pr.yml
name: Run Gradle on PRs
on: pull_request
jobs:
  gradle:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-java@v1
      with:
        java-version: 11
    - uses: gradle/gradle-build-action@v2
      id: gradle
      with:
        arguments: build
    - name: "Comment build scan url"
      uses: actions/github-script@v3
      if: github.event_name == 'pull_request' && failure()
      with:
        github-token: ${{secrets.GITHUB_TOKEN}}
        script: |
          github.issues.createComment({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
            body: '❌ ${{ github.workflow }} failed: ${{ steps.gradle.outputs.build-scan-url }}'
          })