Develocity Artifact Cache and Setup Cache User Manual

How Artifact Cache CLI Works

Artifact Cache CLI stores and restores build artifacts to the Develocity Artifact Cache and Setup Cache service on Develocity Edge nodes through three sequential phases: Restore, Build, and Store. Edge nodes manage the available cache storage through an eviction policy, and Develocity manages access control for Artifact Cache CLI clients.

Artifact Cache and Setup Cache Overview
Artifact Cache and Setup Cache Overview

Hosting the Artifact Cache CLI Binary

 You must host the Artifact Cache CLI binary within your internal network. This is required for security and reliability.

Download the CLI binary and upload it to your internal artifact repository (such as Artifactory, Nexus, or a simple file server). This approach ensures:

  • Control over artifact availability

  • Compliance with corporate security policies

  • Optimal download speeds

Download

You can download the latest version of develocity-artifact-cache-cli JAR file and its associated files from the following links:

curl -L -o develocity-artifact-cache-cli.jar https://docs.develocity.ai/downloads/develocity-artifact-cache-cli/develocity-artifact-cache-cli-1.6.0.jar

To validate the binary:

  1. Download the checksum file:

    curl -L -o develocity-artifact-cache-cli-1.6.0.jar.sha256 https://docs.develocity.ai/downloads/develocity-artifact-cache-cli/develocity-artifact-cache-cli-1.6.0.jar.sha256

  2. Validate the binary against the checksum file:

    echo "$(cat develocity-artifact-cache-cli-1.6.0.jar.sha256)  develocity-artifact-cache-cli.jar" | sha256sum --check

  3. If valid, the output is:

    Output
    develocity-artifact-cache-cli: OK

  4. If the check fails, sha256 exits with nonzero status and prints output similar to:

    Output
    develocity-artifact-cache-cli: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

    Download the same version of the binary and checksum.

Verifying the GPG Signature

The develocity-artifact-cache-cli JAR is published alongside its PGP signature. The public key is published to https://keys.openpgp.org. You can verify the signature as follows:

curl -OL https://docs.develocity.ai/downloads/develocity-artifact-cache-cli/develocity-artifact-cache-cli-1.6.0.jar && \
  curl -OL https://docs.develocity.ai/downloads/develocity-artifact-cache-cli/develocity-artifact-cache-cli-1.6.0.jar.asc && \
  gpg --keyserver keys.openpgp.org --recv-key 15D543CA40743FFA47654C16622DE19DC011B9BE && \
  gpg --verify develocity-artifact-cache-cli-1.6.0.jar.asc develocity-artifact-cache-cli-1.6.0.jar

The output of the last command should look similar to the following:

Output
gpg: Signature made Mon Sep  7 08:05:18 2026 CEST
gpg:                using RSA key D9B2DFBD9F3298BA
gpg: Good signature from "Gradle Inc. <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 15D5 43CA 4074 3FFA 4765  4C16 622D E19D C011 B9BE
     Subkey fingerprint: E287 9931 BCA1 A42E 55F2  D64D D9B2 DFBD 9F32 98BA

This verifies that the artifact was signed with the private key that corresponds to the imported public key. The warning is emitted because you haven’t explicitly trusted the imported key (therefore [unknown]). One way of establishing trust is to verify the fingerprint over a secure channel. Please contact technical support should you want to do so.

Requirements

For system requirements to use Develocity Artifact Cache and Setup Cache, see System Requirements.

Getting Started

See Configuring GitHub Actions and Configuring Jenkins to get started on a specific CI platform.

Artifact Cache CLI Commands

Refer to the Artifact Cache CLI Commands Reference for detailed information on available commands and their usage.

Develocity Artifact Cache and Setup Cache Operation Flow

Artifact Cache CLI connects to a Develocity Edge node and runs three sequential phases for each CI job.

Edge Discovery

The Artifact Cache CLI uses Edge discovery to connect to the optimal Edge:

  1. Artifact Cache CLI reads the access key of a CI agent Develocity user from the environment variable DEVELOCITY_ACCESS_KEY.

  2. Access key identifies a Develocity user.

  3. The CI agent Develocity user has the Edge location configured.

  4. Artifact Cache CLI connects exclusively to that Edge for the Restore and Store phases.

Alternatively, connect directly to a specific Edge node as described in Connecting Without Edge Discovery.

Connecting Without Edge Discovery

The --dv-edge option connects the Artifact Cache CLI to one Edge node, bypassing discovery through the Develocity server. A direct connection has two parts:

  1. Pass --dv-edge=<edge_url> instead of --dv-server=<server_url>.

  2. Include an entry for the Edge host in DEVELOCITY_ACCESS_KEY.

A discovery-based setup doesn’t need the second part. The Artifact Cache CLI authenticates against the Edge it connects to, so a value that covers only the Develocity server host leaves the request unauthenticated and the Edge rejects it.

Restoring From a Specific Edge
export DEVELOCITY_ACCESS_KEY=edge.example.com=abcd1234efgh5678

java -jar develocity-artifact-cache-cli.jar restore \
  --dv-edge=https://edge.example.com \
  --gradle-home=$HOME/.gradle

One access key value can carry entries for several hosts, separated by semicolons. The Artifact Cache CLI uses the entry matching the host it connects to and ignores the others, so a single CI secret can serve both discovery-based and direct connections.

Access Key Covering the Develocity Server and an Edge
export DEVELOCITY_ACCESS_KEY=develocity.example.com=abcd1234efgh5678;edge.example.com=ijkl9012mnop3456

See Environment Variables for the full access key format.

Restore Phase

  1. CI job starts: A fresh ephemeral CI agent is created.

  2. Checkout code: The repository is cloned.

  3. Artifact Cache CLI queries Edge: Requests the image for this job/branch.

  4. Edge returns image: Lists all known artifacts for this job.

  5. Restore artifacts: Artifact Cache CLI downloads artifacts.

 If an existing caching solution is leveraged by the ephemeral CI agent, be aware that it might clash with Artifact Cache and/or Setup Cache, potentially causing suboptimal caching performance or undefined behavior.
The checkout step must be performed before the restore command.

Build Phase

  1. Build runs: The build tool uses the restored artifacts.

Store Phase

  1. Build completes: The build tool process exits.

  2. Artifact Cache CLI scans directories: Identifies new or changed artifacts.

  3. Store new artifacts: Uploads to the Edge node.

  4. Update image: Records the up-to-date artifact list.

  5. Image stored to Edge: The updated image is ready for use by the next CI job.

Observability

Build Scan Reporting

The Common Custom User Data Gradle plugin (version 2.1.0 or above) and Common Custom User Data Maven extension automatically add Artifact Cache and Setup Cache configuration and restore phase metrics to every Build Scan as Custom Values.

Example Build Scan with Artifact Cache and Setup Cache reporting
Example Build Scan with Artifact Cache and Setup Cache Reporting
 The "Artifact Cache: Restore wall-clock duration" value is the total duration of the restore phase from both the Artifact Cache and Setup Cache.

Develocity Reporting and Visualization

The "Dependency Caching" dashboard in Develocity Reporting and Visualization provides an overview of the ratio of dependencies downloaded compared to resolved from the local cache, across all projects and builds. The dashboard supports Gradle and Maven builds running locally and on CI, and detects cached dependency files regardless of the caching solution used. When Artifact Cache is enabled, the visualizations display the actual reduction in dependency downloads achieved by the feature. The dashboard includes filters by build tool, project, and tags to enable in-depth analysis of caching performance.

Dependency Caching Dashboard
Dependency Caching Dashboard

The "Dependency Caching" dashboard requires Develocity 2026.1 and Develocity Gradle plugin 4.4.0 or Develocity Maven extension 2.4.0.

The "Repository Stability" dashboard in Develocity Reporting and Visualization provides an overview of the stability of the remote binary repositories that builds depend on. A repository is unstable when the build process encounters inconsistent or unpredictable download outcomes when resolving dependencies from a repository. Repository instability slows builds even when they ultimately succeed, and in the worst case causes them to fail. With Artifact Cache enabled, the volume of requests to downstream repositories is reduced, improving overall repository and build stability. The dashboard includes filters by build tool, project, and tags to enable in-depth analysis of caching performance.

Repository Stability Dashboard
Repository Stability Dashboard

The "Repository Stability" dashboard requires Develocity 2026.2.0.

Develocity Artifact Cache and Setup Cache Service Monitoring

The Develocity Artifact Cache and Setup Cache service exposed by Edge nodes can be monitored by following the Monitoring section of the Develocity Edge User Manual.