Add building on riscv64 hardware platform

Author: robert-scheck

.github/workflows/image.yml

@@ -112,7 +112,7 @@ jobs:
         with:
           context: .
           file: ./Dockerfile.multiarch
-          platforms: linux/386,linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390x
+          platforms: linux/386,linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/riscv64,linux/s390x
           push: ${{ github.event_name != 'pull_request' }}
           tags: ${{ needs.build.outputs.tags }}
           build-args: ${{ needs.build.outputs.args }}

Dockerfile.multiarch

@@ -36,10 +36,14 @@ LABEL maintainer="Robert Scheck <https://github.com/pdftk-java/pdftk-java-contai
 COPY bcprov.jar commons-lang3.jar pdftk.jar /usr/share/java/
 
 RUN set -x && \
+  case "$(uname -m)" in \
+    "riscv64")  export JRE="openjdk21-jre-headless" SECURITY="/usr/lib/jvm/java-21-openjdk/conf/security/java.security"     ;; \
+    *)          export JRE="openjdk8-jre-base"      SECURITY="/usr/lib/jvm/java-1.8-openjdk/jre/lib/security/java.security" ;; \
+  esac && \
   apk --no-cache upgrade && \
-  apk --no-cache add openjdk8-jre-base && \
+  apk --no-cache add "${JRE}" && \
   ls -l /usr/share/java/ && \
-  jsf=/usr/lib/jvm/java-1.8-openjdk/jre/lib/security/java.security OIFS="${IFS}" IFS=$'\n' && \
+  jsf="${SECURITY}" OIFS="${IFS}" IFS=$'\n' && \
   cp -pf "${jsf}" "${jsf}.bc" && \
   sed -e 's/^security\.provider\.1=.*/security.provider.next/' -e '/^security\.provider\.[0-9].*/d' -i "${jsf}.bc" && \
   for sp in $(grep '^security\.provider\.' "${jsf}"); do \

README.md

@@ -50,7 +50,7 @@ To build a custom OCI image from current Git, e.g. `--build-arg COMMIT=master` n
 
 ## Pipeline / Workflow
 
-[Docker Hub](https://hub.docker.com/) and [Quay](https://quay.io/) can both [automatically build](https://docs.docker.com/docker-hub/builds/) OCI images from a [linked GitHub account](https://docs.docker.com/docker-hub/builds/link-source/) and automatically push the built image to the respective container repository. However, as of writing, this leads to OCI images for only the `amd64` CPU architecture. To support as many CPU architectures as possible (currently `386`, `amd64`, `arm/v6`, `arm/v7`, `arm64/v8`, `ppc64le` and `s390x`), [GitHub Actions](https://github.com/features/actions) are used. There, the current standard workflow "[Build and push OCI image](.github/workflows/image.yml)" roughly uses first a [GitHub Action to install QEMU static binaries](https://github.com/docker/setup-qemu-action), then a [GitHub Action to set up Docker Buildx](https://github.com/docker/setup-buildx-action) and finally a [GitHub Action to build and push Docker images with Buildx](https://github.com/docker/build-push-action).
+[Docker Hub](https://hub.docker.com/) and [Quay](https://quay.io/) can both [automatically build](https://docs.docker.com/docker-hub/builds/) OCI images from a [linked GitHub account](https://docs.docker.com/docker-hub/builds/link-source/) and automatically push the built image to the respective container repository. However, as of writing, this leads to OCI images for only the `amd64` CPU architecture. To support as many CPU architectures as possible (currently `386`, `amd64`, `arm/v6`, `arm/v7`, `arm64/v8`, `ppc64le`, `riscv64` and `s390x`), [GitHub Actions](https://github.com/features/actions) are used. There, the current standard workflow "[Build and push OCI image](.github/workflows/image.yml)" roughly uses first a [GitHub Action to install QEMU static binaries](https://github.com/docker/setup-qemu-action), then a [GitHub Action to set up Docker Buildx](https://github.com/docker/setup-buildx-action) and finally a [GitHub Action to build and push Docker images with Buildx](https://github.com/docker/build-push-action).
 
 Thus the OCI images are effectively built within the GitHub infrastructure (using [free minutes](https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions) for public repositories) and then only pushed to both container repositories, Docker Hub and Quay (which are also free for public repositories). This not only saves repeated CPU resources but also ensures identical bugs independent from which container repository the OCI image gets finally pulled (and somehow tries to keep it distant from program changes such as [Docker Hub Rate Limiting](https://www.docker.com/increase-rate-limits) in 2020). The authentication for the pushes to the container repositories happen using access tokens, which at Docker Hub need to be bound to a (community) user and at Quay using a robot account as part of the organization. These access tokens are saved as "repository secrets" as part of the settings of the GitHub project.