Fix Alpine/master regression tests for ARM64 builds

[jensenbox]

This fixes the Alpine and master Dockerfile regression test failures on ARM64 that @ImreSamu identified in #393.

The problem

PostgreSQL's JIT compilation causes "stuck spinlock" crashes when the regression tests run under QEMU emulation for ARM64. The CI matrix already builds on native ubuntu-24.04-arm runners, but the Alpine and master variants fail during the regression test phase.

The fix

Disable JIT during the regression test database startup by passing --jit=off to pg_ctl:

-    && su postgres -c 'pg_ctl -D /tempdb -c -l /tmp/logfile -o '-F' start '
+    && su postgres -c 'pg_ctl -D /tempdb -c -l /tmp/logfile -o "-F --jit=off" start '

This only affects the build-time regression tests — JIT remains enabled in the final running image.

Applied to both templates and all generated Dockerfiles (11 files, same single-line change).

Testing

• All stable builds pass on both amd64 and arm64 runners (26/26)
• PostGIS spatial queries verified on native Apple Silicon Mac

Fixes #393
Refs #216, #387

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c0cdad5da4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Fail CI when multi-arch manifest creation fails

This || true masks registry and tagging errors, so the release workflow can report success even when a manifest was not actually created or updated; for example, the loop iterates every */Dockerfile version but not every one of those tags is guaranteed to have both -amd64 and -arm64 images available, which means users can keep pulling stale/single-arch tags without any signal in CI.

Useful? React with 👍 / 👎.

[jensenbox]

Good callout. The || true is intentional here because master builds use continue-on-error: true — they build from git HEAD and can fail on one or both architectures. Without || true, a single master build failure would stop the loop and prevent manifests from being created for all the stable versions that did build successfully.

That said, I could tighten this up by failing on stable versions and only tolerating errors on master. Something like:

for dir in */Dockerfile; do
  ver=$(dirname "$dir")
  # master builds are best-effort (continue-on-error in build job)
  fail_ok=false
  [[ "$ver" == *-master ]] && fail_ok=true

  docker manifest create ... || $fail_ok
  docker manifest push ... || $fail_ok
done

Would that be preferred, or is the current approach acceptable given that manifest creation only fails when the arch-tagged images don't exist (which means the build already failed)?