CI fails due to some Python version change:

   ____________ ERROR collecting s3tests/functional/test_s3_website.py ____________
  'yield' keyword is allowed in fixtures, but not in tests (test_routing_generator)

This PR should pass after rebasing to include 17e490e.

This PR should pass after rebasing to include 17e490e.

I now rebased on lastest master including the Python yield CI fix.

Failed with:

Error: buildx failed with: ERROR: failed to solve: docker.io/library/eclipse-temurin:21-jre: failed to resolve source metadata for docker.io/library/eclipse-temurin:21-jre: no match for platform in manifest: not found

Seems Eclipse Temurin OpenJDK 21 is no longer available for linux/arm/v7 on Alpine but just on Ubuntu now.
For the other platforms theres still the Alpine versions.

https://adoptium.net/en-GB/supported-platforms/

The referenced tag:
https://hub.docker.com/layers/library/eclipse-temurin/21-jre/images/sha256-6748d5f5c866e4bb35e1f92db05148735b056588a4e40b466e7cde9dcb84f76f

These are the currently supported architectures of Eclipse Temurin 21 JRE container on Docker Hub:

• linux/amd64
• linux/arm64/v8
• linux/ppc64le
• linux/riscv64
• linux/s390x

arm/v7 was added in #596 and requested in #591

At some point in the future an update of the JRE major version will be necessary.

I am not sure if arm/v7 is really still relevant, as arm64/v8 is probably more in use today.

The situation was actually already analysed by @snpz in #596 (comment)
Basically none of the usual OpenJDK distributions still publish 32-bit ARM pre-built container images to Docker Hub for more recent OpenJDK versions.

As I could also not find reputable base images still published for recent OpenJDK version with arm/v7 support I see two options, either remove this older platform or us a generic OS base image and install a JRE in there.

Alpine as a base image would then also no longer work, as they don't provide an arm/v7 build.

Looks like Debian OpenJDK and Ubuntu OpenJDK would provide builds of OpenJDK for this architecture nicely via the package manager. So the architecture could be kept for the price of a bit bigger base image with this approach.

Ideally from security perspective an even leaner base image like e.g. distroless or chisel would be better and less CVE noise. I think this would be possible with chisel too for more architectures.

@gaul What do you prefer?

• (A Remove arm/v7 pre-built container
• (B) Use Ubuntu (or Debian) base container and their build of the OpenJDK
  • + supports lots of architectures
  • - bit bigger container (with just a bit more CVE noise)
• (C) Ubuntu chisel to build a minimal base container with just Ubuntu build of the OpenJDK
  • + supports lots of architectures
  • + more security, less CVE noise
  • - no package manager, no shell, bit less debug convenience
  • - a bit exotic, compared to more familiar base images

The current MR is the option (A).
I locally tried the option (B) too, that container build is also working fine with just a minimal change in the Dockerfile.
(using ubuntu:24.04 and openjdk-21-jre-headless)
Option (B) as separate MR: #828

(A Remove arm/v7 pre-built container

@snpz added armv7 support in #596. Do you still need this or can you move to arm64? I am skeptical that S3Proxy should support something that the OpenJDK packagers don't want to support. I prefer dropping armv7.

@gaul
Thanks for asking! I don't need the armv7 version anymore since I finally got a more modern device.

Thank you for your contribution @polarctos!

Thanks for the feedback @snpz!