This fork of the upstream Apache ActiveMQ Artemis repository serves as a cached safeguard checkpoint for GitHub Actions to build container images and push them to GHCR and Docker Hub.
Upstream's official Docker Hub repository does not provide images built for the various ARM microarchitectures, in particular,
- the 64-bit ARMv8 microarchitectures, such as the ARM Cortex chipsets, Apple Mac M1, M2, M3 series, Apple's A7-A16 (e.g., Bionic) chipsets, or the Ampere and similar cloud-hosted CPU architectures, or
- the 32-bit ARMv7 microarchitectures used, e.g., in Raspberry Pi SoCs prior to Raspberry Pi 4.
Keeping it as a fork is necessary within GitHub, because GitHub Actions triggers can properly be invoked only on owned repositories when included as submodules. The trick is to synchronize and dispatch a change notification to my builder repo. I accomplish it utilizing the fork synchronization feature, automated by Fork Sync. The updates to the upstream repo are external events wrt. my container builder repository. In order to notify the builder, one could
- either schedule a job in the builder to regularly
fetchthe upstream (pull approach), merge the changes, and run the builder job, or, - in a push approach (as taken hereby), fork-sync and push to my container builder repo via a
repository_dispatchevent.
The former approach would defeat the safeguard purpose. The latter is therefore admissible. (If you know a better approach, just give me a note, that would be very welcome.)
The intended workflow is to have GitHub Actions in the dedicated container-builder repository
- track the upstream branch,
- in case of a version bump or a commit to
origin/main, pull from and open a PR for a merge of the main branch in the upstream repo into theupstreambranch here, - alert the repository owner of the PR,
- have the repository owner approve and either auto-merge or merge the PR to the
mainbranch here, and finally - build and push the new image to the container registries.
This semi-automated CI workflow enables manual halting, potentially applying changes, and evaluating the necessity of the update to the target container repository. Through the PR approval, it serves as a manual approval mechanism for pulling upstream changes into the target container repositories.
The builder repository has a workflow to auto-build
upstream-release-bindist: the upstream bindist release (as provided by the upstream build tools), verbatim, bypassing this repository,upstraem-local-bindist: the upstreammainbranch but through a local bindist built verbatim using GitHub Actions, bypassing this repository,fork-approved: from themainbranch of this repository.
I am making only the container repositories public that are built bypassing this repository.
Private patches and experimental changes are tracked in a separate private repository, which, in turn, is integrated into a private CI pipeline.
I recognized some interest in having ARM container images for Artemis. There were some individual efforts to make it available to everyone. For as long as the upstream does not push their own ARM builds, I am trying to help out as well. But the results are intended for my own private purposes only.
This is a private effort. No warranty, no responsibility, implicit or explicit, use at your own risk. Do your own due diligence. Applying Apache License on my deltas.
Everything made publicly available here is open-source and presented in the most transparent way feasible to me, and is limited by the upstream license.
Without any change, running the container will provide you with a fancy UI console out of the box, which can be reached at http://127.0.0.1:8161/console/ (substitute your actual host IP address or name)
- Post some recent benchmarks covering Artemis, Pulsar, RabbitMQ, Kafka, and some other messaging middleware systems.
What follows is the snapshot of the README.md from the upstream repository at the time of the change in the present forking repository.
ActiveMQ Artemis is the next generation message broker from Apache ActiveMQ.
See the User Manual for an in-depth explanation of all aspects of broker configuration and behavior. The ActiveMQ Artemis Examples repository contains over 90 examples demonstrating many of the client and broker features.
See the Hacking Guide for details about modifying the code, building the project, running tests, IDE integration, etc.
See the Migration Guide for information about the architectural and configuration differences between ActiveMQ "Classic" (i.e. 5.x) and ActiveMQ Artemis.
See our website for details on how to report an bug, request a feature, etc.