Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: BAZEL.md

From https://docs.bazel.build/versions/master/bazel-overview.html Bazel is an open-source build and test tool similar to Make, Maven, and Gradle. It uses a human-readable, high-level build language. Bazel supports projects in multiple languages and builds outputs for multiple platforms. Bazel supports large codebases across multiple repositories, and large numbers of users. RabbitMQ, Tier1 plugins included, is a large codebase. The developer experience benefits from fast incremental compilation. More importantly, RabbitMQ's test suite is large and takes hours if run on a single machine. Bazel allows tests to be run in parallel on a large number of remote workers if needed, and furthermore uses cached test results when branches of the codebase remain unchanged. Bazel does not provide built in Erlang or Elixir support, nor is there an available library of bazel rules. Therefore, we have defined our own rules in https://github.com/rabbitmq/bazel-erlang. Elixir compilation is handled as a special case within this repository. To use these rules, the location of your Erlang and Elixir installations must be indicated to the build (see below). While most of work for running tests happens in Bazel, the suite still makes use of some external tools for commands, notably gnu `make` and `openssl`. Ideally we could bring all of these tools under bazel, so that the only tool needed would be `bazel` or `bazelisk`, but that will take some time. On macOS: `brew install bazelisk` Otherwise: https://docs.bazel.build/versions/master/install-bazelisk.html Create a `user.bazelrc` by making a copy of `user-template.bazelrc` and updating the paths in the first few lines. `bazel run broker` You can set different environment variables to control some configuration aspects, like this: ``` RABBITMQCONFIGFILES=/path/to/conf.d \ RABBITMQ_NODENAME=<node>@localhost \ RABBITMQNODEPORT=7000 \ bazel run broker ``` This will start RabbitMQ with configs being read from the provided directory. It also will start a node with a given node name, and with all listening ports calculated from the given one - this way you can start non-conflicting rabbits even from different checkouts on a single machine. Many rabbit tests spawn single or clustered rabbit nodes, and therefore it's best to run test suites sequentially on a single machine. Hence the `build --localtestjobs=1` flag used in `.bazelrc`. Additionally, it may be reasonable to disable test sharding and stream test output when running tests locally with `--testoutput=streamed` as an additional argument (to just disable sharding, but not stream output, use `--testsharding_strategy=disabled`). Naturally that restriction does not hold if utilizing remote execution (as is the case for RabbitMQ's CI pipelines). Erlang Common Test logs will not be placed in the logs directory when run with bazel. They can be found under `bazel-testlogs`. For instance, those of the rabbit application's backingqueue suite will be under `bazel-testlogs/deps/rabbit/backingqueue_SUITE/test.outputs/`. Note: This takes quite some time on a single machine. `bazel test //...` rabbit is an appropriate example because it encloses the rabbitmq_prelaunch application. `bazel test deps/rabbit/...` `bazel test deps/rabbit_common:all` `bazel test //deps/rabbit:lazyqueueSUITE` `bazel run gazelle-update-repos -- hex.pm/accept@0.3.5` to generate/update `bazel/BUILD.accept` Add/update the entry in MODULE.bazel `bazel run gazelle-update-repos -- --testonly github.com/extend/ct_helper@master` Add/update the entry in MODULE.bazel `bazel run gazelle` `bazel run :moduleindex > moduleindex.yaml` Format all bazel files consistently (requires ): `buildifier -r .` Remove unused load statements from BUILD.bazel files (requires ): `buildozer 'fix unusedLoads' //...:pkg`