Work on multiple RabbitMQ sub-projects, e.g. core broker, plugins, some client libraries, with ease
Switch branches/tags
rabbitmq_v3_7_0_milestone18 rabbitmq_v3_7_0_milestone17 rabbitmq_v3_7_0_milestone16 rabbitmq_v3_7_0_milestone15 rabbitmq_v3_7_0_milestone14 rabbitmq_v3_7_0_milestone13 rabbitmq_v3_7_0_milestone12 rabbitmq_v3_7_0_milestone11 rabbitmq_v3_7_0_milestone10 rabbitmq_v3_7_0_milestone9 rabbitmq_v3_7_0_milestone8 rabbitmq_v3_7_0_milestone7 rabbitmq_v3_7_0_milestone6 rabbitmq_v3_7_0_milestone5 rabbitmq_v3_7_0_milestone4 rabbitmq_v3_7_0_milestone3 rabbitmq_v3_7_0_milestone2 rabbitmq_v3_7_0_milestone1 rabbitmq_v3_6_14 rabbitmq_v3_6_13 rabbitmq_v3_6_13_rc2 rabbitmq_v3_6_13_rc1 rabbitmq_v3_6_13_milestone1 rabbitmq_v3_6_12 rabbitmq_v3_6_12_rc3 rabbitmq_v3_6_12_rc2 rabbitmq_v3_6_12_rc1 rabbitmq_v3_6_11 rabbitmq_v3_6_11_rc3 rabbitmq_v3_6_11_rc2 rabbitmq_v3_6_11_rc1 rabbitmq_v3_6_11_milestone5 rabbitmq_v3_6_11_milestone4 rabbitmq_v3_6_11_milestone3 rabbitmq_v3_6_11_milestone2 rabbitmq_v3_6_11_milestone1 rabbitmq_v3_6_10 rabbitmq_v3_6_10_rc2 rabbitmq_v3_6_10_rc1 rabbitmq_v3_6_10_milestone4 rabbitmq_v3_6_10_milestone3 rabbitmq_v3_6_10_milestone2 rabbitmq_v3_6_10_milestone1 rabbitmq_v3_6_9 rabbitmq_v3_6_8 rabbitmq_v3_6_7 rabbitmq_v3_6_7_rc3 rabbitmq_v3_6_7_rc2 rabbitmq_v3_6_7_rc1 rabbitmq_v3_6_7_milestone6 rabbitmq_v3_6_7_milestone5 rabbitmq_v3_6_7_milestone4 rabbitmq_v3_6_7_milestone3 rabbitmq_v3_6_7_milestone2 rabbitmq_v3_6_7_milestone1 rabbitmq_v3_6_6 rabbitmq_v3_6_6_rc2 rabbitmq_v3_6_6_rc1 rabbitmq_v3_6_6_milestone5 rabbitmq_v3_6_6_milestone4 rabbitmq_v3_6_6_milestone3 rabbitmq_v3_6_6_milestone2 rabbitmq_v3_6_6_milestone1 rabbitmq_v3_6_5 rabbitmq_v3_6_5_milestone2 rabbitmq_v3_6_5_milestone1 rabbitmq_v3_6_4 rabbitmq_v3_6_4_rc1 rabbitmq_v3_6_4_milestone2 rabbitmq_v3_6_4_milestone1 rabbitmq_v3_6_3 rabbitmq_v3_6_3_rc3 rabbitmq_v3_6_3_rc2 rabbitmq_v3_6_3_rc1 rabbitmq_v3_6_3_milestone2 rabbitmq_v3_6_3_milestone1 rabbitmq_v3_6_2 rabbitmq_v3_6_2_rc4 rabbitmq_v3_6_2_rc3 rabbitmq_v3_6_2_rc2 rabbitmq_v3_6_2_rc1 rabbitmq_v3_6_2_milestone5 rabbitmq_v3_6_2_milestone4 rabbitmq_v3_6_2_milestone3 rabbitmq_v3_6_2_milestone2 rabbitmq_v3_6_2_milestone1 rabbitmq_v3_6_1 rabbitmq_v3_6_1_rc2 rabbitmq_v3_6_1_rc1 rabbitmq_v3_6_0 rabbitmq_v3_6_0_rc3 rabbitmq_v3_6_0_rc2 rabbitmq_v3_6_0_rc1 rabbitmq_v3_6_0_milestone3 rabbitmq_v3_6_0_milestone2 rabbitmq_v3_6_0_milestone1 rabbitmq_v3_5_8 rabbitmq_v3_5_7 rabbitmq_v3_5_7_rc2 rabbitmq_v3_5_7_rc1
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.

README.md

Rabbit Public Umbrella

This repository makes it easier to work on multiple RabbitMQ sub-projects at once. It is no longer a requirement for working on an individual plugin (as of the 3.6.0 cycle) thanks to erlang.mk.

Initial Clone

After you clone the umbrella for the first time, use

make co

to clone all dependencies. They will be checked out under deps.

Dependencies (sub-projects) are named after their Erlang application names. Mostly they are self-explanatory but there are some less obvious cases for historical reasons:

  • rabbit is RabbitMQ server
  • amqp_client is RabbitMQ Erlang client (AMQP 0-9-1)
  • rabbit_common is a library shared by the above
  • rabbitmq_server_release contains release automation and packaging bits
  • rabbitmq_java_client also contains integration test suites for the server

Running RabbitMQ from Source

To run a RabbitMQ node built from source without any plugins, change to the deps/rabbit directory and run:

make run-broker

If you need to access log files, see under $TMPDIR/rabbit*.

Running RabbitMQ with Plugins

To build a package, and all its dependencies, cd into the package directory under deps and run make.

To start RabbitMQ from a plugin directory, use make run-broker.

To run a node with multiple plugins, cd into deps/rabbitmq_server_release, and run it with PLUGINS listing the plugins you need:

make run-broker PLUGINS='rabbitmq_management rabbitmq_consistent_hash_exchange'

To run a node built from source with multiple plugins and a config file, use

make run-broker PLUGINS='rabbitmq_management rabbitmq_consistent_hash_exchange' RABBITMQ_CONFIG_FILE=/path/to/config/file

Running Tests

Integration Tests

Integration tests require that you have JDK *+ and Maven 3.x installed. To run all test suites with:

cd deps/rabbitmq_java_client
make tests

Full Server Tests

To run all server tests, use

cd deps/rabbit
make tests

Note that the above can take up to 2 hours depending on the hardware.

To run a subset of the most essential tests:

make ct-fast

Sub-projects

To run tests for a sub-project, run

make tests

from its directory.

Variables That Can Be Set When Building

The following variables can be passed on the 'make' command line in order to configure builds.

  • ERL: the Erlang 'erl' command to use, erl by default

  • ERLC: the Erlang 'erlc' command to use, erlc by default

  • TMPDIR: temporary directory for database directories, logs, etc

  • VERSION, RABBIT_VSN: the RabbitMQ version number, 0.0.0 by default

Packaging

Consider Using a Snapshot

Before building a distribution from source, consider using a snapshot build instead. For contributions that were merged into one of the maintained release branches, there should typically be no reason to build from source as snapshot releases will be published in the next 15 minutes to several hours (depending on the change and how busy the pipeline is).

Producing a Distribution from Source

The distro-specific packaging targets are now integrated into the top-level build system. You should need to do no more than:

make VERSION=3.7.0.snapshot.123 RABBIT_VSN=3.7.0.snapshot.123 UNOFFICIAL_RELEASE=1 dist

to build debs and rpms, along with the source and binary tarballs. If you just want to build one package, you can use the targets debian_packages, rpm_packages or java_packages in the top-level Makefile.

You need to have cdbs installed to build the Debian packages, and rpm for the Fedora packages.

The variable UNOFFICIAL_RELEASE is used to determine whether packages should be signed: if the variable is set then they will not be signed, otherwise they will be. The signing key ID is 056E8E56.

UNOFFICIAL_RELEASE is also used by the Debian target to determine changelog behaviour. If it is not set, then debian/changelog must contain an entry for the version string in <Version>. If it is set, it creates a fake changelog entry.