Develocity Edge User Manual (beta) | Develocity Documentation

Introduction

Develocity Edge makes it easier to provide Develocity services closer to where builds are run and makes builds faster by reducing network latency.

This manual covers setting up an Edge, by creating an Edge in Develocity, installing one or more Edge nodes and connecting the node(s) to Develocity. Also covered by this manual are the steps to enable "Edge discovery" for compatible Develocity plugins and extensions to leverage the Edge network.

Develocity Edge is considered beta. Future releases will expand the functionality provided and may include incompatible changes with past releases.

Requirements

Edge node application

To establish an Edge at least one Edge node must be installed (and connected to Develocity). An Edge node is a server application responsible for processing requests from builds that apply Develocity build agents and for replicating data across the Develocity Edge network.

Use of Gradle’s Edge node software is subject to the Gradle Terms of Use.

The Edge node application is distributed as a Docker image via Docker Hub, and as a executable JAR. Both distributions offer the same functionality.

Older versions of the JAR can be found in the appendix below.

Refer also to the Kubernetes section for information on deploying an Edge node cluster.

Develocity configuration

Establishing an Edge requires configuration changes to be applied to Develocity.

Please refer to the Edge administration using Develocity section to learn more before proceeding to install Edge nodes.

Data directory disk usage

Edge nodes require a single directory, referred to as the “data directory”, to store data and other files.

By default, Edge nodes use all the storage provided by the attached host volume. However, a custom storage usage can be specified using the option --target-size (or the EDGE_NODE_TARGET_SIZE environment variable) to request the application to limit usage.

The Kubernetes quantity format should be used to express large values (e.g. '400M' = 400 megabytes, '2T' = 2 terabytes) for the target size. The value must express a whole number greater than 0 and less than 2^63-1.

Note that the Edge node can inadvertently use more than the configured "target" storage size for log files, config files and other operational files.

CPU & memory

By default, an Edge node uses up to about 2 GiB of memory.

Edge nodes do not require significant CPU resources. Performance is generally constrained by network access to the Edge node.

Java runtime

Edge node and Java version overview
Edge node	Java version
Version 0.1 and later	Java 21

Network

Edges communicate with Develocity over HTTP/1.

Build agents communicate with Edges over HTTP/1, unless the build agent is using Bazel, in which case it communicates over gRPC HTTP/2.

Default network ports bound by Edge node instances
Port	Description
5071	HTTP and gRPC build tool interface
5072	Reserved for application internal use

Edge administration using Develocity

Unattended configuration

It is necessary to adopt Develocity unattended configuration to get started with Develocity Edge. Edge registration keys used to authenticate Edge nodes with Develocity are managed exclusively via unattended configuration.

Unattended configuration can also be used to describe one or more Edges, without using the Develocity Administration user-interface.

Managing Edge registration keys

Edge registration keys allow Edge nodes to authenticate with Develocity. Develocity stores a one-way hashed representation of a secret string that is provided by Edge nodes to establish a session with Develocity. A single registration key can be used across Edges (multiple Edge nodes), but multiple registration keys can be created to facilitate a rolling update if required.

Adding an Edge registration key

To add a new Edge registration key:

Download the latest release of the Develocity Admin CLI.
Execute the Develocity CLI with the config-file hash option.
When prompted, provide a securely random string value as the input. Store the input string securely as it is required for Edge nodes to authenticate with Develocity (see Setting the Edge registration key).
The output from the config-file hash command should be pasted in the list of registration keys.

edge:
  registrationKeys:
  - G6YEkx9wZ6kTUQkXGf/Cn3rh6fLreG2crTfYfn4mkH8=:cCx0vh7SJwpR2VzoeBwUoGI/09/5eg2bNbLdHXxTt6swVmg8bqz+IMOCc+wkT1z7K+3iOvokp2bNJWofbAGi7A==

Revoking an Edge registration key

To revoke an existing Edge registration key:

Remove the key being revoked from the list of registration keys (registrationKeys) in the unattended configuration file.
Import the configuration file to Develocity server.
Apply the change, restarting Develocity if necessary.

Setting the Develocity location name

Develocity server itself is considered an Edge and can have a physical location name associated with it by setting a value for develocityLocationName.

edge:
  develocityLocationName: Tokyo, Japan

This location name will represent Develocity in the "Preferred location" dropdown for Develocity users in the "Location" tab of the "My Settings" page.

Creating Edges

One or more Edges can be created using the unattended configuration file by providing an identifier, location name and public address for each Edge.

Changing the identifier for an existing Edge does not update it, instead overwriting the existing one. Edge nodes that previously connected using the old identifier will fail to register for the Edge at that location.

edge:
  edges:
  - identifier: croatia-1
    locationName: Zagreb, Croatia
    publicAddress: https://edge-croatia-1.mycompany.com
  - identifier: poland-1
    locationName: Warsaw, Poland
    publicAddress: https://edge-poland-1.mycompany.com

Removing Edges

To remove an Edge, remove the Edge from the list of Edges in the unattended configuration file.

For example, the state of configuration having deleted the Edge with the identifier croatia-1 from the example in Creating Edges:

edge:
  edges:
  - identifier: poland-1
    locationName: Warsaw, Poland
    publicAddress: https://edge-poland-1.mycompany.com

Administration user-interface

Edges can be managed using the "Edges" tab of the Develocity Administration user-interface.

Export the Develocity configuration file after making changes in the Develocity Edge Administration user-interface to ensure that the changes are preserved. Refer to the section Unattended configuration for more information.

Creating an Edge

A new Edge can be created by following these steps:

Log in to a Develocity instance as a user with "Administer Develocity" permissions.
Navigate to "Administration > Edges".
Click Create Edge.
Describe the Edge by providing an identifier, public address and the location name.
Click Save to finalize creation.

Editing an Edge

An existing Edge can be edited by clicking on it from the Edges Administration page.

Only the location name and public address fields can be modified.

Deleting an Edge

From the "Edit Edge" screen the Delete button can be used to permanently delete the Edge.

Installing Edge nodes

Setting the Edge registration key

Edge nodes authenticate with Develocity server using an Edge registration key.

The registration key must be provided to the Edge node application at startup by setting the DEVELOCITY_EDGE_REGISTRATION_KEY environment variable.

In this context, the registration key is the one input to the Develocity Admin CLI to be hashed in the Adding an Edge registration key section step-by-step guide.

To do so safely when opting to install an Edge node via Docker or run a node using a JAR file, it is advisable to create a .env file declaring via environment variables the Edge registration key and other start-up parameters.

Example .env file: edge-node.env

EDGE_DEVELOCITY_SERVER=https://develocity.mycompany.com
EDGE_IDENTIFIER=valid-edge-id
DEVELOCITY_EDGE_REGISTRATION_KEY=A1b2C3d4...
EDGE_NODE_TARGET_SIZE=25Gi

This file can then be sourced at the time of executing the Edge node application.

Docker

Specify the path to the .env file using the --env-file option.

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    --env-file /path/to/edge-node.env \
    gradle/edge-node:0.1 \
    start

JAR

1. Create a start-up script that loads the environment variables before running the Edge node. The example script below is for Bash shell.

edge-node-start.sh

#!/bin/bash

EDGE_NODE_ENV_FILE_PATH="$1"

if [ -f .env ]; then
    set -a
    source $EDGE_NODE_ENV_FILE_PATH
    set +a
fi

java -jar edge-node-0.1.jar start

2. Change permissions of the script to make it executable and run the script.

chmod +x ./edge-node.sh
./edge-node.sh "/path/to/edge-node.env"

Kubernetes

Kubernetes users should refer to the Kubernetes section to learn how to apply the Edge registration key as a secret.

Docker

Installation

With Docker installed, an Edge node can be started as follows:

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    --env-file /path/to/edge-node.env \
    gradle/edge-node:latest \
    start

It is assumed that the mandatory start-up parameters are provided in the .env file. Refer to the Setting the Edge registration key section to learn more.

This will download the latest version of the Edge node container image, create a new container from it, then run it with the UID of the current user. The Edge node will use /opt/edge-node on the host to store its files and serve on ports 5071.

Once connected to Develocity server at https://develocity.mycompany.com, the node will be associated with the Edge identified by valid-edge-id.

More information about changing these settings can be found in the following sections.

Airgapped installation

In order to install the Docker Edge node on a host that is not connected to the Internet (i.e. airgapped), you will need to first obtain the image on an Internet connected host, then transfer it to the airgapped destination.

On the non-airgapped system, pull down the latest docker image for the node
```
docker pull gradle/edge-node:0.1
```

Export the image to a file

docker save gradle/edge-node:0.1 --output edge-node.tar

Copy this file across to the airgapped host, and then import the image into docker
```
docker load --input edge-node.tar
```

The node can then be started and configured on the airgapped host in the same manner as a non-airgapped install.

Versioning

The docker latest tag always refers to the most recently released version of the Edge node, however we recommend using an absolute version when using Docker, as latest may give unexpected results when upgrading due to Docker idiosyncrasies.

Binding the data directory

The Edge node container uses /data inside the container as the application data directory. When starting the container, the --volume (or -v) switch should be used to specify which directory on the host to mount to this directory in the container.

If the container is started without a mount for /data, Docker will create a directory on the host in a location of its choosing to use. The anonymous volume won’t be reused between container runs, losing any persisted Edge node data.

Each Edge node must have its own data directory. Sharing a data directory across nodes is not supported.

When choosing where to store the data (i.e. which host directory to mount to /data within the container), be sure to choose a disk volume that has adequate storage capacity to accommodate the desired storage size.

For more information on managing data volumes with Docker, please see this tutorial.

Run-as user

The Edge node docker image does not specify a default user. If a container is started without --user specified, the Edge node application will run as the root user. While Docker containers provide a kind of process sandbox, it is generally recommended to avoid running processes as root inside containers.

Previously, we showed starting the node with the current user by using the arguments --user $UID. If you wish to use a different user ID known to the host, you can replace this $UID with the required user ID.

The command below demonstrates using a user id of 5000:

docker run --detach \
    --user 5000 \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    --env-file /path/to/edge-node.env \
    gradle/edge-node:0.1 \
    start

The Edge node application will read from and write to the file system as this user. The /data directory mount must be readable and writable by this user.

Port mapping

The Edge node container must expose the port 5071 for build tool connectivity (see also Network) These ports need to be mapped to a port on the host in order to expose it.

The following example exposes the HTTP and gRPC build tool interfaces (Gradle, Maven, sbt and Bazel) via port 8443 on the host:

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 8443:5071 \
    --env-file /path/to/edge-node.env \
    gradle/edge-node:0.1 \
    start

Auto start

The Edge node container can be automatically restarted on system boot by leveraging Docker’s restart policies. Starting a node container with --restart always will ensure that it is always running unless explicitly stopped.

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    --restart always \
    --env-file /path/to/edge-node.env \
    gradle/edge-node:0.1 \
    start

Kubernetes

Below is a sample Kubernetes manifest for deploying Edge nodes to a Kubernetes cluster.

An ephemeral volume is mounted to bind the data directory to, and the requested storage should be sized appropriately for the target storage size. You may also need to adjust the allocated CPU and memory resources based on demand and the resources of your cluster.

apiVersion: v1
kind: Service
metadata:
  name: edge-node
spec:
  selector:
    app.kubernetes.io/part-of: gradle-enterprise
    app.kubernetes.io/component: edge-node
  ports:
  - name: http
    port: 5071
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: edge-node
  labels:
    app.kubernetes.io/part-of: gradle-enterprise
    app.kubernetes.io/component: edge-node
spec:
  replicas: 3 # Change this to the desired number of replicas
  selector:
    matchLabels:
      app.kubernetes.io/part-of: gradle-enterprise
      app.kubernetes.io/component: edge-node
  strategy:
    type: RollingUpdate
    rollingUpdate: # Change the strategy to adapt to the count of replicas
      maxUnavailable: 25%
      maxSurge: 25%
  template:
    metadata:
      labels:
        app.kubernetes.io/part-of: gradle-enterprise
        app.kubernetes.io/component: edge-node
    spec:
      securityContext:
        runAsUser: 999
        runAsGroup: 0
        fsGroup: 0
      terminationGracePeriodSeconds: 600
      containers:
      - name: edge-node
        image: edge-node:local
        args: [ "start"]
        ports:
        - name: http
          containerPort: 5071
        resources:
          requests:
            memory: 2Gi
            cpu: "2"
          limits:
            memory: 4Gi
            cpu: "2"
        env:
        - name: EDGE_DEVELOCITY_SERVER
          value: http://gradle-enterprise-app:6011 # Change this to your Develocity server URL
        - name: EDGE_IDENTIFIER
          value: my-edge-1 # Change this identifier to an Edge created in your Develocity installation
        - name: EDGE_REGISTRATION_SECRET
          valueFrom:
            secretKeyRef:
              name: develocity-edge-registration-secret
              key: registration-secret
        volumeMounts:
        - mountPath: /data
          name: edge-node-ephemeral-volume
      volumes:
      - name: edge-node-ephemeral-volume
        ephemeral:
          volumeClaimTemplate:
            spec:
              accessModes: [ "ReadWriteOnce" ]
              resources:
                requests:
                  storage: 25Gi # The Edge node uses as much storage as requested to store data

Adding the registration key as a secret

Use the following kubectl command to create the secret named develocity-edge-registration-secret within the desired namespace. Replace <develocity-edge-namespace> with the actual namespace:

kubectl -n <develocity-edge-namespace> apply -f ./edge-registration-secret.yaml

edge-registration-secret.yaml

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: develocity-edge-registration-secret
  namespace: <develocity-edge-namespace>
stringData:
  registration-secret: "dmVyc2lvbjogNQpyZWdpc3RyYXRp...." # Change to actual registration key from Develocity

Exposing Edge nodes outside your cluster

The sample Kubernetes manifest includes a service for the Edge node named edge-node exposing port 5071. This service uses a ClusterIP for communication meaning it is not accessible outside of the Kubernetes cluster by default. To access the Edge node outside your cluster you will need to create some kind of entry-point to this service into the cluster.

Possible methods for this are via an ingress, explicit node port, external IP service or a load balancer. The method you choose depends on your cluster and network configuration.

Below is a sample Ingress definition:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: edge-ingress
spec:
  tls:
  - hosts:
    - {your-domain-name}
    secretName: {tls-secret-for-your-domain-name}
  rules:
  - host: {your-domain-name}
    http:
      paths:
      - path: /
        pathType: ImplementationSpecific
        backend:
          service:
            name: edge-node
            port:
              name: http

JAR

Running an Edge node

Once you have downloaded the JAR file, refer to the Setting the Edge registration key section to learn how to set the Edge registration key used to authenticate with Develocity.

The Edge node application can be run with the java command and the start subcommand, for example:

java -jar edge-node-0.1.jar start --develocity-server=https://develocity.mycompany.com --edge-identifier=valid-edge-id --target-size=25Gi

This will start an Edge node that is:

Connected to the Develocity server at https://develocity.mycompany.com.
Associated with the Edge named $valid-edge-id.
Storing operation data to a directory inside the $TEMP location
Requested to use at most 25 GiB of storage.

Specifying a custom data directory

It is strongly recommended to specify an explicit data directory location with the --data-dir option:

java -jar edge-node-0.1.jar start --data-dir /opt/edge-node

Each Edge node must have its own data directory. Sharing a data directory between Edge node instances is not supported.

To use the current directory as the data directory, use --data-dir .

Specifying the ports

The default listening ports are 5071 and 5072 (the latter is reserved for application internal usage).

With regard to the former, to use a different port you can use the --port option:

java -jar edge-node-0.1.jar start --port 443 --data-dir /opt/edge-node start

Most systems require superuser privileges to bind to a port lower than 1024.

In the absence of a --port option, the PORT environment variable is also respected.

java -jar edge-node-0.1.jar start --config grpcServer.port=6012 --port 443 --data-dir /opt/edge-node start

Optimized HTTPS

Edge nodes serve HTTPS traffic more efficiently on some platforms. If HTTPS is configured but optimized HTTPS support could not be loaded, the application will emit a warning to the console of:

WARNING: Unable to use optimized HTTPS support as OpenSSL was not found.

Currently, optimized HTTPS support is available on the following platforms:

Linux (aarch_64/x86_64)
macOS (aarch_64/x86_64)
Windows (x86_64)

Auto start

The Edge node JAR provides no built-in mechanism for auto starting on system restart. This must be implemented with your operating system’s process manager or similar.

The following demonstrates how to use systemd, a popular process manager for Linux systems, to achieve this.

1. Create a file, edge-node.sh as root and make it executable, with the following contents:

#!/bin/bash
# Launches Develocity Edge node with correct arguments
# Should be run with CAP_NET_BIND_SERVICE rather than as the superuser
EDGE_DEVELOCITY_SERVER=https://develocity.mycompany.com
EDGE_IDENTIFIER=valid-edge-id
DEVELOCITY_EDGE_REGISTRATION_KEY=A1b2C3d4...
EDGE_NODE_TARGET_SIZE=25Gi

java -jar /absolute/path/to/edge-node-0.1.jar start

2. Create a file, /etc/systemd/system/develocity-edge.service as root, with the following contents:

[Unit]
Description=Develocity Edge
After=network.target
StartLimitIntervalSec=0

[Service]
# To improve security you should create a separate user to run the Edge node
#User=gradle
#Group=gradle
# Allow using ports below 1024, required if not run as the superuser
AmbientCapabilities=CAP_NET_BIND_SERVICE
Restart=always
RestartSec=1
ExecStart=/absolute/path/to/edge-node.sh

[Install]
WantedBy=multi-user.target

3. Run the following to start the Edge node for the first time:

systemctl start develocity-edge

4. Run the following to have systemd start the Edge node on system boot:

systemctl enable develocity-edge

Post-installation setup

Verify connectivity

The Edge node has a /ping HTTP endpoint to test connectivity, which can be used to test if it is reachable for users in general. For example, if you are running an Edge node locally, without SSL, and are using the default listening port, then you can access this endpoint at http://localhost:5071/ping.

Connectivity to an Edge node can be tested by running the following command on hosts/computers which need to connect:

curl -sw \\n --fail-with-body --show-error https://<edge-node-host>/ping

It should return SUCCESS.

Logging

The logs for an Edge node are located in the «data-dir»/logs directory. Logs are automatically rotated. The latest log file is named node.log (the latest log file is always «data-dir»/logs/node.log).

Increasing memory limits

By default, the Edge node uses 2 GiB of heap memory and 500MiB of off heap memory. If you need to allocate more memory, the application can be configured as follows:

Docker

The value for heap and off heap memory is set using an environment variable called JAVA_OPTS in the docker run instruction.

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    --env JAVA_OPTS="-Xms3g -Xmx3g -XX:MaxDirectMemorySize=1g" \
    gradle/edge-node:0.1 \
    start

Kubernetes

The value for heap and off heap memory is set using an environment variable called JAVA_OPTS for the container in the Kubernetes manifest. It is important that the container resources are also adjusted accordingly.

containers:
- name: edge-node
  args: [ "start" ]
  env:
  - name: JAVA_OPTS
    value: "-Xms3g -Xmx3g -XX:MaxDirectMemorySize=1g"
  resources:
    requests:
      memory: 3Gi
    limits:
      memory: 6Gi

JAR

The value for heap and off heap memory is set using the standard JDK parameters when running the JAR.

java -jar edge-node-0.1.jar -Xms3g -Xmx3g -XX:MaxDirectMemorySize=1g

Leveraging Edges in builds

Gradle and Maven Develocity plugins provide an opt-in “Edge discovery” option, which uses the user’s location setting in Develocity to automatically assign an Edge to use as a remote build cache. The Develocity Edge with “Edge discovery” removes the need for extra local build configuration and allows Edge locations and instances to be updated dynamically as the Develocity server manages all configuration.

Develocity users can set their location in the "My Settings - Location" page of the Develocity user-interface.

This feature can be used only when access key authentication is used by the build.

Gradle usage

(Develocity Gradle plugin 3.19+)

Kotlin

develocity {
    server = uri("https://develocity.mycompany.com")
    edgeDiscovery = true
}

Apache Maven™ usage

(Develocity Maven extension 1.23+)

develocity.xml

<develocity>
  <server>
    <url>https://develocity.mycompany.com</url>
    <edgeDiscovery>true</edgeDiscovery>
  </server>
</develocity>

Using HTTPS

By default, the Edge node serves over HTTP. Using HTTPS requires extra configuration.

Using your own certificate

To use your own certificate, specify the path to an X.509 certificate (including intermediates) using the cert-file option and the path to your PKCS#1 or PKCS#8 private key using the key-file option. Both files must be in PEM format.

java -jar edge-node-0.1.jar start --cert-file ./ssl.crt --key-file ./ssl.key

Or when using the Docker image:

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    gradle/edge-node:0.1 \
    start
    --cert-file /data/ssl.crt --key-file /data/ssl.key

Using a generated certificate

You can have the server generate its own self-signed certificate to use. To do this, specify the --generate-self-signed-cert argument to the node application.

java -jar edge-node-0.1.jar start --generate-self-signed-cert

Or when using the Docker image:

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    gradle/edge-node:0.1 \
    start
    --generate-self-signed-cert

This certificate will not be trusted by clients, and will require extra configuration by clients.

Please consult the Gradle user manual or Develocity Maven Extension User Manual for how to configure Gradle or Maven builds to accept an untrusted SSL connection.

Allowing untrusted SSL connections

By default, the Edge node will not allow connections to Develocity if they serve over HTTPS and present untrusted certificates (e.g. self-signed). In order to allow such connections, the Edge node must be started with the --allow-untrusted-ssl argument, as follows:

Docker

docker run --detach \
    --user $UID \
    --volume /opt/edge-node:/data \
    --publish 5071:5071 \
    gradle/edge-node:0.1 \
    start --allow-untrusted-ssl

Kubernetes

containers:
- name: edge-node
  args:
  - start
  - "--allow-untrusted-ssl"

JAR

java -jar edge-node-0.1.jar start --allow-untrusted-ssl

Importing additional trusted SSL certificates

By default, the Edge node uses the default trust settings of the Java runtime that it runs with when connecting to Develocity or other Edge nodes using SSL. If your organization uses certificates that are not signed by a trusted certificate authority, you must perform additional configuration for this to work. This may be the case if you use self-signed certificates or an internal certificate authority.

Any additional certificates to trust must be added to a single PEM file. The application can then be configured as follows:

Docker

The PEM file needs to be created as «data-dir»/conf/trusted-ssl.crt, the certificates are installed during container startup.

Kubernetes

The contents of the PEM file must be created as a secret called trusted-ssl, under the key trusted-ssl.crt.

kubectl create secret generic trusted-ssl --from-file=trusted-ssl.crt

The trusted-ssl secret is mounted as a volume to the Edge node at the path /data/conf/trusted-ssl.crt

spec:
  template:
    spec:
      containers:
      - name: edge-node
        args: [ "start" ]
        volumeMounts:
        - mountPath: /data/conf/trusted-ssl.crt
          name: trusted-ssl
          subPath: trusted-ssl.crt
          readOnly: true
      volumes:
      - name: trusted-ssl
        secret:
          secretName: trusted-ssl

JAR

Additional certificates are configured using the standard keytool utility of your JDK distribution.

Appendix A: Release history

0.1

12th December 2024

[NEW] First release of Develocity Edge node providing build caching services.

Appendix B: JAR downloads

edge-node-0.1.jar (SHA-256 checksum, PGP signature, PGP signature SHA-256 checksum)

Appendix C: Verifying the signature of the Edge node artifacts

The Edge node JAR and schema are published to docs.gradle.com alongside its signatures. The public key is published to https://pool.sks-keyservers.net and https://keys.openpgp.org. You can verify the signature of the JAR as follows:

$ curl -OL https://docs.gradle.com/edge-node/jar/edge-node-0.1.jar && \
  curl -OL https://docs.gradle.com/edge-node/jar/edge-node-0.1.jar.asc && \
  gpg --keyserver keys.openpgp.org --recv-key 7B79ADD11F8A779FE90FD3D0893A028475557671 && \
  gpg --verify edge-node-0.1.jar.asc edge-node-0.1.jar

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

gpg: Signature made Thu Sep 28 16:17:46 2023 CEST
gpg:                using RSA key 893A028475557671
gpg: Good signature from "Gradle Inc. <info@gradle.com>" [unknown]
gpg:                 aka "Gradle Inc. <maven-publishing@gradle.com>" [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: 7B79 ADD1 1F8A 779F E90F  D3D0 893A 0284 7555 7671

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 (hence [unknown]). One way of establishing trust is to verify the fingerprint over a secure channel. Please contact technical support should you wish to do so.