[synkronus] Update CI to build multiplatform OCI images using podman

[r0ssing]

Component

• formulus (React Native mobile app)
• formulus-formplayer (React web app)
• synkronus (Go backend server)
• synkronus-cli (Command-line utility)
• Documentation
• Other (please specify)

Feature Description

This issue covers two related improvements:

1. Add multi-platform (multi-arch) Docker/OCI images
2. Replace Docker-based builds with Podman-based builds

Currently, images are only published for linux/amd64, and ARM users must build locally.

Problem Statement

• ARM is now common (Apple Silicon, Raspberry Pi, servers)
• Users cannot simply podman pull (or docker pull) and run
• Local builds add friction and setup time
• Current build pipeline depends on Docker rather than a fully FOSS toolchain

Proposed Solution

1. Publish multi-platform images for:

   • linux/amd64
   • linux/arm64

2. Switch build pipeline from Docker to Podman

   • Use Podman/Buildah for building images
   • Continue publishing standard OCI images to registry (e.g. GHCR)

Result:

• Users can podman pull (or docker pull) and get the correct image automatically
• No manual builds needed for ARM
• Build pipeline aligns with FOSS principles

Additional Context

• Multi-platform images are standard practice
• Podman is a daemonless, fully open-source alternative to Docker
• OCI images remain fully compatible with Docker and other runtimes

[bokchan]

I wanna align on the approach.
In conversation with Copilot I suggest one of the following flows.

Option A — Buildah + Podman + Skopeo (single job) ✅ Recommended

• Buildah builds each arch image and assembles the OCI manifest list
• Podman handles GHCR login and post-publish pull verification
• Skopeo inspects the pushed manifest and resolves the digest for attestation
• Each stage (build / assemble / push / verify) is a discrete, auditable step
• Most explicit FOSS-native replacement; failure point is always clear
• Moderate workflow verbosity: tag and label logic lives in shell, not hidden in an Action

Option B — Podman-only (single job)

• Podman handles the entire flow: login, build, manifest assembly, push, and pull test
• Simpler tool story for contributors: one CLI for everything
• Manifest assembly is slightly less explicit than Buildah's dedicated manifest commands
• Debugging cross-arch failures can be less obvious than with Option A
• Still requires shell-based tag and label logic
• Viable if maintainers prefer minimal tooling surface

Option C — Split jobs by architecture

• Separate amd64 and arm64 build jobs run in parallel
• A final job assembles the manifest and publishes to GHCR
• Cleanest GitOps shape: build artifacts first, publish second
• Easiest to isolate arch-specific build failures
• Significantly more YAML; artifact handoff between jobs adds complexity
• Likely more structure than this workflow currently needs

---

	Option A	Option B	Option C
Tools	Buildah + Podman + Skopeo	Podman only	Buildah + Podman + Skopeo
Job structure	Single job	Single job	Multiple jobs
Parity with current workflow	High	Medium-High	High
Multi-arch support	High	High	High
Explicitness / debuggability	High	Medium	High
Workflow complexity	Medium	Low-Medium	High
Recommendation	✅ Best balance	Viable simpler alternative	Likely overbuilt

---

My recommendation is Option A: a single-job Buildah + Podman + Skopeo workflow with GHCR and fork-safe owner-derived image names.

Ask: are maintainers aligned with that approach, and does first-pass parity need to include Docker Buildx-like caching, or can cache optimization be handled in a follow-up?

[bokchan]

I looked at existing github workflows on the marketplace. However, none of them can be used as a direct replacement.
This is the most promising would have been the following: https://github.com/marketplace/actions/build-and-push-with-podman
However, the --platform param is hardcoded to linux/amd64 so it would require some adaptation to work for this use-case...