Daz DeBoer 97715a29bc Redesign the caching Job Summary (#985)
Redesigns the caching section of the Job Summary into a single,
consistent layout across every cache provider and state, and integrates
the provider message into the report rather than appending it
disconnected at the bottom.

## Motivation

The caching report was produced by three divergent code paths (NoOp /
basic / enhanced), each rendering its own markdown:

- **Explicitly disabled** → a one-line message, no expand, no provider
note.
- **Enhanced** (incl. skipped-due-to-existing-home) → a full `<details>`
block.
- **Basic** → a one-line message with **no** expandable details at all.

The Enhanced/Basic provider note floated at the very bottom,
disconnected from the report.

## What changed

`save()` now returns structured `CacheReport` data instead of
pre-rendered HTML, and a single renderer (`caching-report.ts`) produces
one unified layout for all variants:

- **Section heading**: `#### <icon> Gradle Caching — <Provider>
(<status>)`
- **Status line** explaining what the cache did
- **Integrated provider note** woven in under the heading — now shown
**unconditionally** (no longer gated on license acceptance)
- **Expandable cache-entry details** when there are entries — basic
caching now gets this too

The two disabled variants (explicitly disabled, and skipped due to a
pre-existing Gradle User Home) render as **compact callouts with no
expandable section**.

### Main repo
- `caching-report.ts` (new): central renderer + all framing copy + entry
table/`<pre>` helpers.
- `cache-service.ts`: `CacheReport` / `CacheEntryReport` / status types;
`save()` returns `CacheReport`.
- `cache-service-loader.ts`: `NoOp` returns a report;
`LicenseWarningCacheService` removed; new `getProviderNote()`.
- `cache-service-basic.ts`: builds a `CacheReport`.
- `job-summary.ts` / `setup-gradle.ts`: thread `CacheReport` +
`ProviderNote`.
- `configuration.ts`: remove now-unused `isCacheLicenseAccepted()`.

### Vendored library
The structured contract requires **gradle-actions-caching v0.7.0**
(gradle/actions-caching#74). This PR updates the vendored library to
that release — the official `Update gradle-actions-caching library to
v0.7.0` vendor commit is included here, so merging this PR ships the
redesign together with the library it depends on.

## Testing

- Both repos build; prettier + eslint clean.
- `gradle/actions`: 363/363 Jest tests pass, including new
`caching-report.test.ts` covering every variant.
- `gradle-actions-caching`: 74/74 pass under JDK 17.
- Rendered markdown verified for all five variants (enhanced/basic
enabled & read-only, disabled, skipped).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Bot Githubaction <bot-githubaction@gradle.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-12 15:21:52 +00:00
2026-06-10 16:15:39 +00:00
2026-06-10 10:14:48 -06:00
2026-06-10 08:54:56 -06:00
2026-06-10 08:54:56 -06:00
2026-04-02 08:45:40 -06:00
2019-09-21 20:57:04 +02:00
2026-04-03 15:25:10 -06:00
2026-06-09 19:55:28 -06:00

GitHub Actions for Gradle builds

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

Note

Choice of caching providers in v6

To provide the fastest possible build experience this action includes Enhanced Caching via gradle-actions-caching, an optimized provider powered by proprietary technology. This feature is free for all public repositories and is currently available as a Free Preview for private repositories.

Prefer a 100% Open Source (MIT) path? We also provide a Basic Caching provider as a thin wrapper over actions/cache. This provider is free for all repositories (public and private) and can be enabled at any time by setting cache-provider: basic.

For a full breakdown of the components, usage tiers, and our Safe Harbor data privacy commitment, see our Distribution & Licensing Guide.

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@v6
    - name: Setup Java
      uses: actions/setup-java@v5
      with:
        distribution: 'temurin'
        java-version: 17
    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@v6
    - 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@v6
    - name: Setup Java
      uses: actions/setup-java@v5
      with:
        distribution: 'temurin'
        java-version: 17
    - name: Generate and submit dependency graph
      uses: gradle/actions/dependency-submission@v6

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.

Starting with v4 the setup-gradle action will perform wrapper validation on each execution. If you are using setup-gradle in your workflows, it is unlikely that you will need to use the wrapper-validation action.

Example workflow

name: "Validate Gradle Wrapper"

on:
  push:
  pull_request:

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

See the full action documentation for more advanced usage scenarios.

Languages
TypeScript 54.9%
Groovy 19.2%
Shell 17.2%
Batchfile 5.6%
JavaScript 1.9%
Other 1.2%