Add zodb-pgjsonb based storage support

[erral]

• I signed and returned the Plone Contributor Agreement, and received and accepted an invitation to join a team in the Plone GitHub organization.
• I verified there aren't any other open pull requests for the same change.
• I followed the guidelines in Contributing to Plone.
• I successfully ran code quality checks on my changes locally.
• I successfully ran tests on my changes locally.
• If needed, I added new tests for my changes.
• If needed, I added documentation for my changes.
• I included a change log entry in my commits.

---

If your pull request closes an open issue, include the exact text below, immediately followed by the issue number. When your pull request gets merged, then that issue will close automatically.

Closes #

See documentation changes at: plone/documentation#2081

[jensens]

Would be easier to use env vars with cookiecutter-zope-instance plus helpers in the entrypoint, see https://plone.github.io/cookiecutter-zope-instance/how-to/use-environment-variables.html

However, this would be a breaking change here and probably worth a PLIP.

So back to reality: Given the limitations how this image built is designed yours is the best and a valid solution to add a new config variants here.

[fredvd]

This is very cool, thank you for the contribution. 😍

We likely can’t test it until we merge and rebuild / release, or?

Also needs an update to docs after testing/feedback.

[erral]

This is very cool, thank you for the contribution. 😍

We likely can’t test it until we merge and rebuild / release, or?

Also needs an update to docs after testing/feedback.

Yes, it is hard to test.

That's why I built locally the images with the said changes and pushed to our container-registry here in GitHub and I am basing a project's Dockerfile on those.

# syntax=docker/dockerfile:1
ARG PLONE_VERSION=6.2.0rc1
FROM ghcr.io/codesyntax/plone-backend/server-builder:${PLONE_VERSION}-pgjsonb-1 AS builder

RUN apt-get update && apt-get install -y openssh-client git
RUN mkdir -p ~/.ssh && echo "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
WORKDIR /app


# Add local code
COPY scripts/ scripts/
COPY . src
COPY zope.ini etc/

# Install local requirements and pre-compile mo files
RUN --mount=type=ssh,id=default <<EOT
    set -e
    bin/pip install mxdev uv
    sed -i 's/-e .\[test\]/./g' src/mx.ini
    cd /app/src
    # remove potentially existing virtualenv from local build
    rm -rf .venv
    ../bin/mxdev -c mx.ini
    ../bin/uv pip install -r requirements-mxdev.txt
    ../bin/python /compile_mo.py
EOT

FROM ghcr.io/codesyntax/plone-backend/server-prod-config:${PLONE_VERSION}-pgjsonb-1

LABEL maintainer="CodeSyntax <plone@codesyntax.com>" \
    org.label-schema.name="codesyntax-web-backend" \
    org.label-schema.description="codesyntax backend image." \
    org.label-schema.vendor="CodeSyntax"

# Copy /app from builder
COPY --from=builder /app /app

RUN --mount=type=ssh,id=default <<EOT
    set -e
    ln -s /data /app/var
EOT

The container-registry is public here on GitHub, so you can test it if you want.

[fredvd]

@erral @jensens. @gforcada @sneridagh @mauritsvanrees @davisagli @ericof

A bit longer introduction: I started reconfiguring the plone-frontend ci/cd to fully run on github hosted arm/x86 runners. @sneridagh experimented and I fine tuned the setup for the 19.x (main) branch, and I'm now also trying it for the maintenance 18.x branch.

There we have the extra complexity that we build both yarn and pnpm containers, with -yarn addition. Also I didn't want to risk overwriting successfully published images, so I added SUFFIX parameterisation to add '-buildtest, also into the Dockerfile, because a variant finished image needs to 'FROM" from its variant base images. (think this still breakd plone-frontend 18.x building for the pnpm image)

Once we have this stable I want to move over plone-backend. And we have several open wishes for a -next variant where we introduce newer features while the main image keeps stable, like #167 and we have a similar challenge in plone-frontend with EOLed Node, where some fixes can keep it running under an -eolsupport variant.

Variants need to be managed/parameterised/stored somwhere. And either we duplicate the repostiry, duplicate on branches, or duplicate on the workflow / Dockerfile level. And that's where I found out about Docker 'bake', where you can build variants following a hcl spec, parameterise on the lowest level and then handoff the variant bake matrix to buildx.

See where this is going to ? ;-) I haven't used the hcl stuff yet, have to experiment and fix our dependency on hosted runners first, but then this is the next fix.

The biggest question mark for me is integrating the hcl matrix, inside the split x86/arm64 image bulding and then stichting that we have coded in to the GHA workflows.

I really want to generate official zope-pgjsonb 'variant' images from the work in this branch, but keeping separate branches from variants if we go that direction, will be a huge maintenance. The further we can parameterise 'down' and keep the upper layers (repo/branch/workflows) generic, the less maintenance / duplication copy-paste.

There is a limit on the 6.2.1-next-pgjsonb-pyruvate-python315 variants you can add to an image, including all combinations. So we need some discusison here, if it possible to put multiple features under one variant if they don't bite each other (like pyruvate and zope-pgjsonb support).

Any experience with https://docs.docker.com/build/bake/ ?

[jensens]

@fredvd you are OT here. OT too: See my comment above: variants by env vars is what i use in my images all the time. I rarely use the official image, because its way too complex and difficult to use - and breaks the flow (cookiecutter-zope-instance in dev, something completely different (and worse and incomplete) for the image).
But: this is an own ticket, not here.