slapd(8) currently segfaults on Actions no
matter what OS or OpenLDAP version we try.
We would be better off with a green build and
a functioning v4.0.x pipeline than the status quo.
Running slapd(8) in a container might help.
This is something to investigate.
(cherry picked from commit 1e76a74587)
Builds now execute on the github actions workers, using Google Cloud Storage (GCS) as a cache
(cherry picked from commit a6874e39cc)
# Conflicts:
# .github/workflows/update-elixir-patches.yaml
# .github/workflows/update-otp-patches.yaml
# MODULE.bazel
# WORKSPACE
# deps/rabbitmq_peer_discovery_consul/test/system_SUITE_data/consul.hcl
* Fix some dialyzer build system errors in make (#11014)
* make amqp10_common dialyze green in make
* make rabbitmq_ct_client_helpers dialyze green with make
* fixup rabbitmq_prelaunch path ref
* Cleanup unused dep_* vars
* Fixup xref for rabbitmq_ct_helpers
I could not figure out how to make xref aware of the cli code without
also checking the cli code as well, and reporting additional errors
* remove unused file
* fix make diaylze for rabbitmq_stream_common
* update deps/oauth2_client/Makefile to match Bazel
(cherry picked from commit 4ec33c8678)
# Conflicts:
# deps/amqp10_common/test/serial_number_SUITE.erl
* fixup backport
---------
Co-authored-by: Rin Kuryloski <rin.kuryloski@broadcom.com>
* Add bazel-test make target so that we can run tests in bazel quickly
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Co-authored-by: Philip Kuryloski <kuryloskip@vmware.com>
This is helpful when we want to ensure a clean slate, which is what
happens when deps of deps go out of sync, and builds / tests start
failing for unexpected reasons.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
`rabbit` is now packaged as any plugins and `rabbit_common`. There is no
need for a second copy of its beam files.
At the same time, we stop copying the `priv` directory and headers for
the same reason.
... in the source dist recipe.
This is required when running the recipe in MSYS2 because Erlang runs
with regular Windows paths, not the MSYS2 namespace.
This allows including additional applications or third party
plugins when creating a release, running the broker locally,
or just building from the top-level Makefile.
To include Looking Glass in a release, for example:
$ make package-generic-unix ADDITIONAL_PLUGINS="looking_glass"
A Docker image can then be built using this release and will
contain Looking Glass:
$ make docker-image
Beware macOS users! Applications such as Looking Glass include
NIFs. NIFs must be compiled in the right environment. If you
are building a Docker image then make sure to build the NIF
on Linux! In the two steps above, this corresponds to Step 1.
To run the broker with Looking Glass available:
$ make run-broker ADDITIONAL_PLUGINS="looking_glass"
This commit also moves Looking Glass dependency information
into rabbitmq-components.mk so it is available at all times.
Like other packaging files, they should not be part of RabbitMQ itself.
One day, they will probably be moved to a dedicated repository, like
other packaging files.
Once the monorepo is built, from within it one can run `make
fetch-topic-branch-${TOPIC_BRANCH}` then `make
topic-branch-${TOPIC_BRANCH}` to rebase the commits from all the
sources back onto the monorepo
Add GitHub Actions workflows for Erlang/OTP 22.3 & 23.0.
The workflows run tests for each component that is now part of this
repo, with test suite parallelization specifically for the rabbit
erlang application.
Because we set the PROJECT_VERSION when we build the Docker image, this
change saves us having to search for the RABBITMQ_VERSION to
PROJECT_VERSION mapping that happens at the top of the Makefile in order
to understand how this ends up in the final Docker image.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Otherwise this target will fail. It's worth making this target slower
but always working rather than fast but it may not work if the dependent
generic-unix version wasn't built before.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
make package-generic-unix PROJECT_VERSION=3.9.0-20200207
make docker-image PROJECT_VERSION=3.9.0-20200207
docker run -it --rm pivotalrabbitmq/rabbitmq:3.9.0-20200207
Re 53a34fc368
cc @dcorbacho
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Some of the flags that we currently use are not recognised, so rather
than adding a third set of flags, let's just ignore everything for now
and circle back to this when it becomes an issue.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
We hit the case where the exported Hex cache could not be read again
using `file:consult/2` when we try to restore the ETS table. The problem
was some string generated with `io_lib:format("~p")` which had invalid
Unicode characters according to `file:consult/1`.
The error returned by `file:consult/1` was:
{51,file_io_server,invalid_unicode}
We are now using `~w` instead of `~p` so string detection is skipped by
io_lib. The result is readable by `file:consult/1`, though the text file
is barely readable by a human now.
They are unused now, since rabbit is provided as an .ez archive.
While here, don't copy include files as well: they are not enough to
build a RabbitMQ plugin anyway.
We can do because Cuttlefish is now used as a library and configuration
is managed at runtime by the RabbitMQ node, not by a preliminary
execution of cuttlefish(1).
... by using the `override` directive to enforce our internal value.
As a reminder, this a hack to convince mix(1) to work offline and use a
copy of the Hex.pm cache provided in the source archive.
Note that this file was moved from rabbitmq-common. It has no use there
and it avoids the need to go through the entire CI pipeline if we want
to change this file.
The `stats.mk` file was also moved to the new `mk` subdirectory to avoid
file pollution at the root of this project.
E.g.:
● Release v3.7.10 [Latest]
Assets: 36
Downloads: 47.67k
Date: 1/7/2019
Author: @pivotal-rabbitmq-ci
There is an interactive variant, in case one wants to try out different flags.
Both targets depend on Docker, so that the host on which they run does
not get polluted with node.js & friends. All containers use a volume for
the node_modules so that subsequent runs are faster.
Those that run *BSD or Linux might want to adapt this for their
platform. This feels good enough as a first spike, which is yet to
survive the meticulous @dumbbell or the veteran @michaelklishin
Michael Klishin
Michael Klishin
Rin Kuryloski
mergify[bot]
Michal Kuratczyk
Rin Kuryloski
Loïc Hoguin
Michael Klishin
Gerhard Lazu
Gerhard Lazu
Jean-Sébastien Pédron
Gabriele Santomaggio
Philip Kuryloski
Jean-Sébastien Pédron