Build multi-arch Docker images (amd64 + arm64)

[flozano]

Summary

• Add linux/arm64 platform support to all Docker image build and update workflows, producing manifest lists so docker pull automatically selects the correct architecture
• Add QEMU emulation setup and a platforms input to both composite actions (docker_image_builder and docker_image_update)
• Keep otobo-selenium-chrome as linux/amd64 only since the upstream selenium/standalone-chrome base image does not publish arm64 variants

Details

All base images already support arm64:

Base image	arm64 support
perl:5.40-bookworm	Yes
elasticsearch:8.19.3	Yes
nginx:mainline-trixie	Yes
mariadb:lts-noble	Yes
redis:8-bookworm	Yes
selenium/standalone-chrome	No (amd64 only)

The existing Build step with load: true remains single-platform for the sanity check (docker run inspection). Only the Push step uses the platforms input to build and push for all specified architectures.

6 files changed, 52 insertions added. No Dockerfiles were modified.

Test plan

• otobo.web.dockerfile builds successfully for linux/arm64 (verified locally on Apple Silicon — all Debian packages install, all CPAN modules compile)
• otobo.elasticsearch.dockerfile builds successfully for linux/arm64 (verified locally — both ingest-attachment and analysis-icu plugins install)
• No architecture-specific logic in any Dockerfile (no TARGETARCH, no hardcoded binary downloads)
• Trigger a CI run to verify the full matrix builds on GitHub Actions runners

[bschmalhofer]

Hi Franzisco, @flozano ,

thanks for your contribution. This looks very sane to me. We will discuss internally at Rother OSS whether we want this for the next patch level releases or possible only for the upcoming rel-11_1.

Best regards,
Bernhard

[flozano]

hi, thanks for considering it!

[flozano]

CI test results: multi-arch build validated

Ran a build-only test workflow on a fork (no push, no secrets needed) to verify all Docker images compile for both linux/amd64 and linux/arm64.

All 4 multi-arch images built successfully:

Image	Time	Platforms	Result
otobo-elasticsearch	2m 15s	amd64 + arm64	✅
otobo-nginx-webproxy	2m 38s	amd64 + arm64	✅
otobo-nginx-kerberos-webproxy	5m 21s	amd64 + arm64	✅
otobo-web	1h 0m 17s	amd64 + arm64	✅

Notes:

• The otobo-web image takes ~1 hour because CPAN XS modules are compiled under QEMU emulation on x86_64 runners. All CPAN modules (including C extensions like Crypt-Eksblowfish, HTML-Parser, Params-Classify, etc.) compiled cleanly for arm64.
• A follow-up commit bumps docker/setup-qemu-action from v3 to v4 to address the Node.js 20 deprecation warning (forced to Node.js 24 starting June 2, 2026).
• otobo-selenium-chrome was excluded from the test as it remains linux/amd64 only (upstream selenium/standalone-chrome has no arm64 variant).
• Build time could be significantly improved in the future by using GitHub's native ARM runners (ubuntu-24.04-arm) instead of QEMU emulation.

[svenoe]

Hi Francisco,

as Bernhard mentioned, we are currently working on preparing 11.1 for release, we won't have the time to include this into the release though. At the same time, it is not really OTOBO functionality per se, anyways, so we are considering adding those images after 11.1 is done.

Thanks for the contribution, Sven