* use the official erlang image as the base
(no more openssl and erlang recompilation)
* by default, build with OTP27 for x86 only but make it
easy to request any other OTP version and an ARM64 image
* better docker layer caching
* simplify the workflow and the Dockerfile
when splitting the image, depending on the platform, docker buildx
cannot always see the imported image. So, we'll just push to GHCR
always. Members of the rabbitmq github org can log into GHCR, and be
able to perform local builds of the image
Also rework elixir dependency handling, so we no longer rely on mix to
fetch the rabbitmq_cli deps
Also:
- Specify ra version with a commit rather than a branch
- Fixup compilation options for erlang 23
- Add missing ra reference in MODULE.bazel
- Add missing flag in oci.yaml
- Reduce bazel rbe jobs to try to save memory
- Use bazel built erlang for erlang git master tests
- Use the same cache for all the workflows but windows
- Avoid using `mix local.hex --force` in elixir rules
- Fetching seems blocked in CI, and this should reduce hex api usage in
all builds, which is always nice
- Remove xref and dialyze tags since rules_erlang 3 includes them in
the defaults
We need these to debug various rabbitmq-related issues. Ephemeral debug
containers are not enabled on GKE Autopilot (not sure if GKE enables
this alpha feature at all), so we are doing this instead.
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").
Backport to v3.9.x & v3.8.x if build passes
Pair @Gsantomaggio
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
This is the best way of ensuring that everything works. RabbitMQ is not
just the core components, it's all the plugins that ship with it. While
we don't expect anyone to enable all plugins at the same time (for
example enabling all peer discovery plugins at the same time doesn't
make sense), we need to be minimally confident that everything works.
As we work on & QA various features in dev, this is the quickest way of
doing just that.
For example, today we were testing some Stream features with
@GSantomaggio and discovered that we needed to use a different image for
it, pivotalrabbitmq/rabbitmq-stream, because in the dev image we don't
enable the stream plugin by default. There is no reason why we would
need a different container image to test a core feature, that ships part
of RabbitMQ as a Tier 1 plugin. To be honest, I strongly believe that
everyone be looking at these specific images (otp-max & otp-max-1) which
bundle the majority of the RabbitMQ experience in a single artefact,
including OpenSSL & Erlang.
While I would normally push this straight into the main branch, I'm
doing it as a PR so that the following notice, and have the opportunity
to comment on this standalone:
- @michaelklishin
- @GSantomaggio
- @Zerpet
- @MirahImage
- @ansd
As next steps, after all checks pass, can someone from the above list
action the following please:
- merge into our main branch
- backport to v3.9.x
- deploy to lre-3-9
🙌
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
See https://github.com/docker-library/rabbitmq/pull/492
Co-authored-by: Michal Kuratczyk <mkuratczyk@vmware.com>
Ensure compilation and runtime Erlang are in sync
Bump to Ubuntu 20.04
docker-library/rabbitmq also uses Ubuntu 20.04
Before this, someone would need to run the package-generic-unix and
docker-image make targets in order to produce a container image. This
wouldn't always work: more than one archive in the PACKAGES dir, VERSION
& RABBITMQ_VERSION had to be specified, + characters in VERSION. It also
required me to have Docker running, which I am reluctant to leave
running on macOS because it uses CPU even when idle, and starting it
every time that I wanted an ad-hoc container image implied waiting a few
minutes, and then waiting another 15 minutes for the container image to
be produced and published to hub.docker.com.
This commit delegates all the above to GitHub Actions. The best part is
that it happens asynchronously - every commit triggers it - and a
container image for that commit will appear on hub.docker.com within ~15
minutes. In other words, anyone can test any commit in their container
runtime within 20 minutes, without needing to lift a finger. No Docker,
no make targets, just reference the new tag (matches the git sha) and
off you go. It's the beginning of something better, for sure.
Did some cleanup in the Dockerfile part of this. Dropped
RABBITMQ_VERSION build arg, env & commented steps. This is cruft that we
no longer need or even use.
Also fixed VERSION in push target and broken the dependency on dist so
that they can be run independently.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
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.
Michal Kuratczyk
Michal Kuratczyk
Michael Klishin
Rin Kuryloski
Rin Kuryloski
Gerhard Lazu
David Ansari
Loïc Hoguin
Jean-Sébastien Pédron