This repository contains the release for RabbitMQ for Cloud Foundry. It is deployable by BOSH in the usual way.
This release is now using BOSH v2 job links and cloud config and requires at least BOSH Director v255.5
Even though the default branch is release, you should push changes to main. The release branch is the default so that bosh.io can find our releases.
| Job | Status |
|---|---|
| unit tests | |
| integration tests |
Clone the repository and install dependencies.
$ bundle installOnce you have a BOSH Lite up and running locally, run scripts/deploy-to-bosh-lite.
To deploy the release into BOSH you will need a deployment manifest. You can generate a deployment manifest using the following command:
bosh interpolate \
--vars-file=manifests/lite-vars-file.yml \
manifests/cf-rabbitmq-template.ymlAlternatively, you can use the scripts/generate-manifest in order to generate a vanilla manifest for BOSH lite.
Currently, the release has only been tested to run on manual networks (https://bosh.io/docs/networks/).
Run bundle exec rake --tasks to list all the test subsets.
To run only unit tests locally, run: scripts/unit-test.
Integration tests require this release to be deployed into a BOSH director (see Deploying section above).
To run integration tests do scripts/integration-test.
Sometimes testing BOSH releases can lead to writing many tests at the top of the test pyramid, which can increase the feedback loop. Also when tests fail debugging can be hard given there are many components working together.
Embedded release tests are jobs that we deploy in a co-located way so that we can execute tests within a given deployment, inside a VM. The goal is to pull tests down the test pyramid trying to shorten the feedback loop and bring the tests closer to the code.
To execute embedded release tests you need to co-locate the tests within the release being tested and deploy. The deployment should fail if the tests fail. The tests we use can be found in the test release repo.
Back in time Multitenant Broker Release used to live in the same Github repository as cf-rabbitmq-release, but not anymore. We have split both releases into two different repositories. They do different things and have different lifecyle, which explains our decision to do that.
A collection of ops-files and vars-files, features from Bosh 2 CLI, can be used to generate manifests. You’ll find a folder called manifests in both repositories with a manifest template, some ops-files and example of vars-files. It's not required to have two different deployments for cf-rabbitmq-release and cf-rabbitmq-multitenant-broker-release. In case you want to colocate both jobs you can leverage this ops-file to colocate them in the same deployment.