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, Artifactory Query Language (AQL) queries, or existing Release Bundles.

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 (or a draft version finalized), files can't be added, modified, or deleted. In addition, any subsequent changes to the properties of the source artifacts aren't reflected in the Release Bundle. To change a Release Bundle, you must create a new version.

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

JFrog Artifactory tracks all actions related to the Release Bundle version, including its creation, each time it's promoted to a new environment, and when it's distributed. This transparency helps you trust the process that produced the software release.

Types of Release Bundles

The following sections describe the different types of Release Bundles.

Release Bundles v1

If you use Enterprise+, you may be familiar with the concept of Release Bundles, which are used exclusively by JFrog Distribution to distribute releases to Edge services 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 you can use as the vehicle within JFrog 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.

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.

Frequently Asked Questions

This section provides answers to frequently asked questions.

Related Topics

• Release Lifecycle Management
• Create Release Bundles v2
• Release Lifecycle Management Workflow
• Distribute Release Bundles v2
• Release Lifecycle Management CLI