build(renderer): build engine and service images from a released version #7

Merged
james.maes merged 1 commits from fix/renderer-images into develop 2026-11-09 02:39:58 +00:00
Owner

What

renderer/Dockerfile and bridges/remote-renderer/Dockerfile copied *-0.1.0-SNAPSHOT.jar, but the reactor version is ${revision} (1.x), so neither built a released version. Both now resolve the released qbit-document-renderer / qqq-remote-renderer-transport and their runtime libraries at an exact, required RENDERER_VERSION / TRANSPORT_VERSION from the QRun-IO Gitea Maven registry and Maven Central (via a small release-image/pom.xml per image; Maven checks registry checksums). SNAPSHOT and *forge* versions are refused. Reviewed hardening is unchanged (digest-pinned BUILD_IMAGE/JAVA_IMAGE, UID 65532, Zint built from vendor/, no reactor build context). Adds renderer/IMAGE-PUBLISH.md (repeatable build, scan, publish steps and the 1.0.0 pins) and renderer/image-pins.sh (prints the gg-forge-cd classpath and SHA256 pins from a published image).

No image-publishing workflow exists in this repo, so none is added; the manual steps are documented.

Version

1.0.0. renderer/ and bridges/remote-renderer/ sources are identical between v1.0.0 and v1.1.0-RC.1, and gg-forge pins 1.0.0. Versus the 2026-11-05 local qualification (a 0.1.0-forge build): transport source is unchanged; the engine gained the barHeight refusal (UNSUPPORTED_BARCODE_OPTION) for fixed-geometry encoders and GS1 DataBar stacked (10b3a71), plus OpenHTML now at the family version. Java, Zint and patchset hashes and all third-party JAR hashes are identical to the local image.

Verified

  • mvn -B -pl renderer,bridges/remote-renderer/transport -am verify in the reviewed Maven image (no skip flags): 15 + 174 + 19 tests, 0 failures, Checkstyle clean, BUILD SUCCESS.
  • Both images built from 1.0.0 and pushed to ghcr.io/gg-engineering/qqq-document-renderer and qqq-remote-renderer (tag 1.0.0, manifest digests in IMAGE-PUBLISH.md flow).
  • Service image run read-only, non-root, caps dropped, no-new-privileges; over real mTLS (ephemeral certs) it answered CATALOG, and rendered PDF (Code128, GS1-128, Zint DotCode) and ZPL.
  • Trivy (vuln, HIGH/CRITICAL): 0 in Java JARs; 2 HIGH in the pinned Ubuntu base (apt/libapt-pkg6.0t64 2.8.3, fixed 2.8.4ubuntu0.1), not fixable without changing the reviewed base digest.

Not verified

No cluster run, no handshake against Forge, no gVisor/hostile-input qualification (service is TRUSTED_LAB only), no byte-for-byte rebuild of the OpenHTML jar from vendor/, pull-secret read access to the new packages.

🤖 Generated with Claude Code

## What `renderer/Dockerfile` and `bridges/remote-renderer/Dockerfile` copied `*-0.1.0-SNAPSHOT.jar`, but the reactor version is `${revision}` (1.x), so neither built a released version. Both now resolve the released `qbit-document-renderer` / `qqq-remote-renderer-transport` and their runtime libraries at an exact, required `RENDERER_VERSION` / `TRANSPORT_VERSION` from the QRun-IO Gitea Maven registry and Maven Central (via a small `release-image/pom.xml` per image; Maven checks registry checksums). SNAPSHOT and `*forge*` versions are refused. Reviewed hardening is unchanged (digest-pinned `BUILD_IMAGE`/`JAVA_IMAGE`, UID 65532, Zint built from `vendor/`, no reactor build context). Adds `renderer/IMAGE-PUBLISH.md` (repeatable build, scan, publish steps and the 1.0.0 pins) and `renderer/image-pins.sh` (prints the gg-forge-cd classpath and SHA256 pins from a published image). No image-publishing workflow exists in this repo, so none is added; the manual steps are documented. ## Version 1.0.0. `renderer/` and `bridges/remote-renderer/` sources are identical between `v1.0.0` and `v1.1.0-RC.1`, and `gg-forge` pins 1.0.0. Versus the 2026-11-05 local qualification (a `0.1.0-forge` build): transport source is unchanged; the engine gained the `barHeight` refusal (`UNSUPPORTED_BARCODE_OPTION`) for fixed-geometry encoders and GS1 DataBar stacked (10b3a71), plus OpenHTML now at the family version. Java, Zint and patchset hashes and all third-party JAR hashes are identical to the local image. ## Verified - `mvn -B -pl renderer,bridges/remote-renderer/transport -am verify` in the reviewed Maven image (no skip flags): 15 + 174 + 19 tests, 0 failures, Checkstyle clean, BUILD SUCCESS. - Both images built from 1.0.0 and pushed to `ghcr.io/gg-engineering/qqq-document-renderer` and `qqq-remote-renderer` (tag `1.0.0`, manifest digests in `IMAGE-PUBLISH.md` flow). - Service image run read-only, non-root, caps dropped, no-new-privileges; over real mTLS (ephemeral certs) it answered CATALOG, and rendered PDF (Code128, GS1-128, Zint DotCode) and ZPL. - Trivy (vuln, HIGH/CRITICAL): 0 in Java JARs; 2 HIGH in the pinned Ubuntu base (`apt`/`libapt-pkg6.0t64` 2.8.3, fixed 2.8.4ubuntu0.1), not fixable without changing the reviewed base digest. ## Not verified No cluster run, no handshake against Forge, no gVisor/hostile-input qualification (service is TRUSTED_LAB only), no byte-for-byte rebuild of the OpenHTML jar from `vendor/`, pull-secret read access to the new packages. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
james.maes added 1 commit 2026-11-09 02:07:32 +00:00
build(renderer): build the engine and service images from a released version
maven / build (push) Successful in 6m2s
build / maven (push) Successful in 6m2s
e19feb01a8
Both Dockerfiles copied 0.1.0-SNAPSHOT jars that the reactor no longer produces
(version is ${revision}), so neither built a released version. They now resolve the
released qbit-document-renderer and qqq-remote-renderer-transport (and their runtime
libraries) at an exact, required RENDERER_VERSION / TRANSPORT_VERSION from the
QRun-IO Gitea Maven registry and Maven Central, refusing SNAPSHOT and local
(*forge*) versions. The reviewed hardening is unchanged: digest-pinned
BUILD_IMAGE/JAVA_IMAGE, non-root 65532, read-only-root friendly, Zint built from
vendor/. The reactor build context is no longer needed.

Adds IMAGE-PUBLISH.md (repeatable build/scan/publish steps and the 1.0.0 pins) and
image-pins.sh (prints the gg-forge-cd classpath and SHA256 pins from a published
image). Images for 1.0.0 were built, smoke-tested over mTLS and published to GHCR
under gg-engineering by hand; no workflow publishes images.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
james.maes merged commit e762dac5d5 into develop 2026-11-09 02:39:58 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: QRun-IO/qbit-document-generation#7