This repository contains Actions workflows that produce open source RabbitMQ releases. The goal of this automation is to eventually produce alphas (development snapshots), betas (early previews of new feature releases), release candidates and signed GA releases.
Continuously produced development builds (alphas in RabbitMQ parlance) can be found on the Releases page.
It has a sibling project, rabbitmq/erlang-packages, which produces
Debian packages of Erlang and Elixir, as well as RPM packages of Erlang.
For every merge or push to rabbitmq/rabbitmq-server that involves code changes, a new alpha release build, tag and preview
release is produced and published as a release in this repository.
Alpha builds are identified using a shortened commit SHA, for example, 4.1.0-alpha.af0d8206.
Tags for alphas use a timestamp-based naming scheme. This helps keeps all releases chronologically
ordered on the releases page.
Alpha build artifacts are meant to be used for development, providing feedback on pull requests, and so on.
Alpha builds are not published to Debian and RPM package repositories because it is arguably easier to
install a one-off package with dpkg -i than set up a repository.
Alpha build artifacts are signed. Only a certain number alpha releases are retained.
Beta releases are produced by manually triggering a 4.1.x Beta release workflow.
Beta build artifacts are signed.
RC releases are produced by manually triggering a 4.1.x RC release workflow.
RC build artifacts are signed. They are also published to Debian and RPM repositories, primarily as a way to test that code path before a final release is produced.
GA releases, also called final releases, are meant for end user consumption.
They are signed, distributed via rabbitmq/rabbitmq-server releases and use the standard (for RabbitMQ)
tag structure.
Version naming is generally consistent and follows a long-established RabbitMQ tag
naming pattern. The only exception with this iteration of our release infrastructure
is alpha releases: instead of monotonically incrementing integers used for betas, RCs,
alphas use a short commit SHA, for example, 4.1.0-alpha.3e509c9f.
The commit SHA refers to a commit in the main RabbitMQ server repository.
If an alpha build is triggered manually and there's no commit SHA to use, a different preview identifier (such as a UNIX timestamp) can be used.
| Release type | Tag name pattern | Example |
|---|---|---|
| alphas | alphas.{timestamp} | alphas.1731626175221 |
| betas | {base}-beta.{preview_identifier} | 4.1.0-beta.1 |
| RCs | {base}-rc.{preview_identifier} | 4.1.0-rc.1 |
| final | {base} | 4.0.4 |
Team RabbitMQ maintains two release series. Currently they are 4.1.0 in main and 4.0.x on the v4.0.x branch.
With some exceptions covered below, for every series, there are workflow for producing alphas, betas, RCs and final releases. They follow a naming convention, for example
4.0.x-alpha-release4.1.x-beta-release4.1.x-rc-release4.0.x-ga-release
and so on.
These workflow have certain differences but most of their jobs and steps are very similar or identical. Therefore, they use a reusable release workflow with different inputs.
Some workflows may be intentionally omitted, for example, betas are usually only produced for the release series
in development (4.1.0 at the moment of writing) and not the current generally available release.
Defines the branch of source repositories (rabbitmq/rabbitmq-server, rabbitmq/rabbitmq-packaging) that will be
used during the build.
Such as 4.1.0 or 4.0.4. Usually this value will come from
a repository-specific variable.
This variable is meant to be updated as releases come out.
A boolean that tells the workflow that the release is a preview (an alpha, a beta or an RC) and not a final release.
Produced GitHub releases will be marked accordingly.
alpha, beta or rc
This is 1 in 4.1.0-beta.1 or d46e83277 in 4.1.0-alpha.d46e83277.
This value can be any string but for alpha builds, it usually will be a short commit SHA
in the RabbitMQ server repository, and for beta and rc builds, it will be a user-provided
monotonically increasing number.
A GitHub repository where a release will be created. For beta, RC and final releases, this typically
will be rabbitmq/rabbitmq-server.
For alphas, rabbitmq/server-packages (this repository) will be used instead to not pollute the
release history of a repository with thousands of visitors a month.
What should the resulting GitHub release be entitled?
Resulting GitHub release description.
For alphas, this will include a timestamp and a link to the commit message in the RabbitMQ server repository.
For beta, RC and final releases, it makes more sense to use a release notes file.
What the Git tag should be used for this release?
For alpha builds, a timestamp-based tag such as alphas.41x.{timestamp} will be generated to preserve
more or less chronological ordering of releases even when they are built for multiple series.
Should the produced release artifacts be GPG-signed?
Currently this is set to true for all release types.
Should Debian and RPM packages be published to package repositories?
This primarily makes sense for RC and final releases but not betas and certainly not alphas.
Allows you to override the repository and publish RCs separately from final releases.
A release build involves a few key operations:
- Given a set of inputs, compute the version that should be used
- Produce a source tarball
- Build a generic binary package for Linux, macOS, BSD, and so on
- In parallel, build Debian, RPM and two Windows packages (binary Windows build and a NSIS-based Windows installer and uninstaller)
- Collect all artifacts and sign them
- If necessary, publish Debian and RPM packages to external package repositories
- Create a Git tag and a GitHub release with the produced artifacts and signatures
Artifact signing keys are used at different steps:
- When building a Debian package, by
dpkg-buildpackage(1). Given that on Debian-based systems, theapttoolchain works with repository signatures and not package signatures, this is of limited use for production deployments (wheredpkg -iis virtually never used) - When building an RPM package. Practical usefulness is generally comparable to that of Debian packages
- When building a Windows installer (and uninstaller), the signature is embedded using
osslsigncode(1) - All artifacts collected for the release are signed with
gpgand the resulting signatures (.ascfiles) are uploaded to the resulting GitHub release together with the actual packages
For steps 1 and 2, the key is loaded into a temporary GPG keychain. Then Debian and RPM tooling fetches a key by ID from that keychain.
For steps 3 and 4, the signing key used comes from GitHub secrets and is stored on disk for only for the relevant parts of the build.
A successfully built alpha release triggers a Jepsen workflow run
in a separate repository, rabbitmq/jepsen.
Team RabbitMQ's package tests (that is, they test Debian, RPM, Windows packages specifically and not RabbitMQ per se) are not yet moved to this repository.
This repository is released under the Mozilla Public License 2.0, same as open source RabbitMQ.
SPDX-License-Identifier: MPL-2.0