This change includes some fixes like setting the suffix for the metadata
which is necessary since 6692fcb6. The main reason for this change
though is to switch from running the integration_SUITE from the
AWS peer discovery plugin from Bazel to make, a necessary step to
dropping the Bazel files.
This fixes a regression from 6692fcb6: setting the `labels` to the
output of the metadata step attaches useful standardized labels like
the git hash when built, the source URL and the created timestamp.
Actions like `int128/wait-for-docker-image-action` used in the
`peer-discovery-aws` workflow use the revision label to detect that the
latest image has the desired hash.
Without setting `labels` we seem to inherit the version label from the
base erlang image:
$ docker image inspect -f '{{ json .Config.Labels }}' \
pivotalrabbitmq/rabbitmq:sha-0e7b53c6a8b682411c3f0024691a4760d8219699-otp27
{"org.opencontainers.image.version":"27.2.1"}
* 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
... instead of 4.0.3.
[Why]
We need the following bugfixes:
* one in the Khepri reset code backported in #12739 and published in
RabbitMQ 4.0.4.
* one in the quorum queue code backported in #12850 and published in
RabbitMQ 4.0.5.
Too many people check the box that says they
have read the community support policy but they
haven't actually read anything because
they expect support for RabbitMQ 3.13 and earlier
3.x versions without having a support license
or being regular contributors.
[Why]
Our alpha packages published to `rabbitmq/server-packages` use letters
in addition to digits and dots.
[How]
Accept any string that starts with a digit as the version here. We just
enforce the prefix and the filename extension.
The digit at the beginning it here to exclude the
`rabbitmq-server-generic-unix-latest-toolchain-*.tar.xz` archive.
[Why]
Using the `fetch-gh-release-asset` action outputs work fine for our
official releases, but it does not for our alphas published to
`rabbitmq/server-packages` because the filenames use another version
compared to the GitHub release.
[How]
Always derive the version from the archive filename. This is safe
regardless of what the GitHub release states.
... not any release.
[Why]
Once we release RabbitMQ 4.1.0, it means that the `v4.1.x` branch would
be tested against 4.1.x, i.e. itself.
Note that we will have to update this pinned version from time to time
if needed.