Understanding Release Bundles v2

Release Bundles group together the contents that comprise the bill of materials for your software releases. Each Release Bundle specifies the files and packages that comprise a release, along with their metadata.

Release Bundles exist as a series of one or more versions, each of which must contain at least one artifact. Release Bundles may include source artifacts from local and Federated repositories only. A new Release Bundle can be created in several ways, including from builds, individual artifacts, AQL queries, or existing Release Bundles.

📘

Note

Release Bundles cannot contain source artifacts that contain the same path and name from different repositories (known as a path collision).

Since all the artifacts specified in a Release Bundle are required to keep the release coherent, a Release Bundle version is immutable. Effectively, this means that once a Release Bundle version has been created, files cannot be added, modified, or deleted. In addition, any subsequent changes to the properties of the source artifacts are not reflected in the Release Bundle. To change a Release Bundle, a new version must be created.

Each Release Bundle is stored in a Release Bundle repository with a unique name and version per project.

Artifactory tracks all actions related to the Release Bundle version, including its creation, each time it is promoted to a new environment, and when it is distributed. This transparency increases customer confidence in the process that resulted in the software release.

Types of Release Bundles

The different types of Release Bundles are described below:

Release Bundles v1

Many Enterprise+ customers are familiar with the concept of Release Bundles, which are used exclusively by JFrog Distribution to distribute releases to Artifactory Edge nodes located at remote sites. This type of Release Bundle is now known as v1.

Release Bundles v2

Release Lifecycle Management introduces Release Bundles v2, which can be used as the vehicle within Artifactory for promoting and distributing a release through its lifecycle from the build stage through production.

Release Bundle v2 Repositories

A Release Bundle v2 is stored as self-contained evidence in a read-only repository with the special package type, ReleaseBundles. The Release Bundle repository is created automatically when the first Release Bundle is created.

The Release Bundle specification is stored as a JSON file located under the path {rb-repository-key}/{rb-name}/{rb-version} and is signed with a DSSE signature in a Base64-encoded envelope.

In addition to the Release Bundle specification, each Release Bundle contains a snapshot of all included artifacts. Deleting any source artifact from the original path does not compromise the consistency of the contents of the Release Bundle.

The name of the repository used for all Release Bundles created outside the context of a specific project is release-bundles-v2. For project-specific Release Bundles, the following prefix is added to the name: {project-key}-release-bundles-v2.

📘

Note

Any attempt to add a prefix to the Release Bundle repository name that does not match the project name will result in an error.

Release Bundles v2 and Docker Manifests

A Docker manifest is a JSON file that describes image variants for multiple platforms. If source artifacts contain a Docker manifest (manifest.json or list.manifest.json), the manifest is resolved automatically during Release Bundle v2 creation. This means the Release Bundle will include both a manifest and all Docker image layers.

You can disable this behavior using the REST API. For more information, see Create Release Bundle v2 Version.