Download the CLI
A custom CI pipeline workflow needs the Artifact Cache CLI JAR file on the CI agent before it can access Artifact Cache or Setup Cache. There are two ways to put it there: fetch it from a Develocity Edge node, or host a copy inside your own network.
| If on GitHub Actions or Jenkins, please refer to the Configuring GitHub Actions or Configuring Jenkins guides. |
For the versions released so far and what changed in each, see Release History.
Downloading From an Edge Node
Develocity Edge nodes serve the develocity-artifact-cache-cli JAR file, so a CI job fetches the CLI from the Edge it already uses for the cache.
You host nothing, and the version a CI agent receives is the version the job requested.
Requesting a version that an Edge does not yet hold makes Develocity download it from the public release channel, verify its checksum, and pass it to the Edge, which retains it for later requests. An operator can also seed a version, which serves it without any access to the public release channel.
This method requires Edge node 2.3.0 or later, connected to Develocity 2026.3.0 or later.
Download Command
Request an exact version from your Edge, authenticating with the same Develocity access key your builds use for the cache:
curl --fail --location \
--connect-timeout 5 --max-time 120 \
--retry 3 --retry-delay 3 --retry-max-time 180 \
--header "Authorization: Bearer ACCESS_KEY" \
--output develocity-artifact-cache-cli.jar \
https://edge.example.internal/edge/assets/artifact-cache-cli/1.7.0The retry and timeout options keep a transient network fault from failing the job. The body timeout is longer than you would set against your own artifact repository, because the first request for a version an Edge does not hold waits for Develocity to fetch and verify it.
The access key’s user needs permission to read Build Cache data, which CI agent users configured for Artifact Cache already have.
Add this step to your CI job before the restore command. The JAR file runs the same way whichever method you use: see Artifact Cache CLI Commands Reference.
Verification
Develocity verifies the JAR file’s SHA-256 checksum against the published checksum before an Edge stores it. The Edge does not serve the checksum or the PGP signature files alongside the JAR file, so a CI job cannot repeat that verification locally. To verify a release yourself, download it from the release channel as described in Hosting the Binary Yourself.
For the endpoint reference, the storage and eviction behavior, and the seeding procedure, see Serving the Artifact Cache CLI in the Develocity Edge User Manual.
Hosting the Binary Yourself
Download the CLI binary, upload it to your internal artifact repository (such as Artifactory, Nexus, or a file server), and point your CI jobs at that copy. Host the binary yourself when your security process requires reviewing every binary before it runs on a build machine, or when your Edge nodes predate 2.3.0.
Keeping the binary inside your network gives you:
-
Control over artifact availability
-
Compliance with corporate security policies
-
Download speeds within your own network
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.7.0.jarTo validate the binary:
-
Download the checksum file:
curl -L -o develocity-artifact-cache-cli-1.7.0.jar.sha256 https://docs.develocity.ai/downloads/develocity-artifact-cache-cli/develocity-artifact-cache-cli-1.7.0.jar.sha256 -
Validate the binary against the checksum file:
echo "$(cat develocity-artifact-cache-cli-1.7.0.jar.sha256) develocity-artifact-cache-cli.jar" | sha256sum --check -
If valid, the output is:
Outputdevelocity-artifact-cache-cli.jar: OK
-
If the check fails,
sha256exits with nonzero status and prints output similar to:Outputdevelocity-artifact-cache-cli.jar: 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 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.7.0.jar && \
curl -OL https://docs.develocity.ai/downloads/develocity-artifact-cache-cli/develocity-artifact-cache-cli-1.7.0.jar.asc && \
gpg --keyserver keys.openpgp.org --recv-key 15D543CA40743FFA47654C16622DE19DC011B9BE && \
gpg --verify develocity-artifact-cache-cli-1.7.0.jar.asc develocity-artifact-cache-cli-1.7.0.jarThe output of the last command should look similar to the following:
gpg: Signature made Mon Sep 7 06:05:18 2026 UTC 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 Develocity support to arrange that.
|
This key signs |