Wraps Stalwart in EAS so iOS/Android native Mail/Calendar 'Exchange'
accounts get two-way mail+calendar+contacts sync (BackendCombined:
IMAP + CalDAV /dav/cal/%l/ + CardDAV, credentials pass through).
- services/zpush: Z-Push 2.6.4 (AGPLv3, see LICENSE-NOTES.md) on
php:8.2-apache-bookworm (trixie dropped libc-client); PHP 8 sysv
sprintf fatal sed-patched; autodiscover dispatcher answers
mobilesync schema, proxies outlook schema to Stalwart unchanged
- prod: zpush Deployment (replicas:1, Recreate — file sync state),
/Microsoft-Server-ActiveSync Ingress on mail.dezky.eu (no redirect,
POST-heavy), autodiscover.dezky.eu repointed to the dispatcher,
selectorless stalwart-imaps/-smtps Services (host-Stalwart is
implicit-TLS only: 993/465, no plain 143/587 — verified on node1)
- CI: build+deploy zpush like the other apps
EAS tops out at 14.1: covers native mobile clients, NOT the Outlook
mobile app (needs 16.1) and not new Outlook for Windows (no EAS).
When an app's typecheck failed, its build job was SKIPPED — which the
deploy condition tolerates (so other apps still ship) — but the deploy
script keyed on the change flags alone and pinned the never-built image
tag, ImagePullBackOff'ing the app (happened to portal on f6bac10).
Deployable now means changed AND build result == success; otherwise the
app keeps its live image, including in the manifest-apply path.
A 'changes' job diffs the push range (github.event.before..sha; falls back
to everything on first/force pushes and when this workflow file itself
changes) and gates per-app typecheck/test/build jobs. Deploy is asymmetric
on purpose: app-only changes roll just the changed Deployments via
kubectl set image; manifest changes (fleet/apps/**) apply the kustomization
with every app pinned to its live image (or this push's sha) so an apply
never resets unchanged apps to :latest. Docs-only pushes run nothing.
The per-job GITHUB_TOKEN is no longer accepted by the container registry's
/v2/ basic-auth endpoint since the act_runner -> gitea/runner switch (login
fails 'unauthorized' before push). Use a personal access token with package
read+write scope, provided as the REGISTRY_TOKEN repo secret.
Push to main = release: after build, a deploy job pins each app image to the
commit SHA (kustomize edit set image), kubectl-applies fleet/apps and waits
for the rollouts. The runner already runs in-cluster, so it reaches the API
server on the in-cluster service IP with a kubeconfig for the new ci-deployer
ServiceAccount (namespace-scoped admin, KUBECONFIG_B64 repo secret).
The drafted Flux sync/image-automation layer is removed — a GitOps controller
plus bot tag-bump commits is more machinery than a single-node cluster needs.
Sortable image tags and $imagepolicy markers go with it.
Also: per-router ACME-safe HTTP->HTTPS redirects for the app ingresses,
platform-api prod config completed (Authentik JWT/JWKS + admin API, Stalwart
via the cni0 gateway IP, OCIS/cold-storage placeholders until those tiers
exist) and the secrets template/README updated to match.
After typecheck + test pass on main, build portal/booking/platform-api images
(matrix) via the dind sidecar and push to git.lastcloud.io tagged latest + SHA.
Auth uses the runner's job token against the same Gitea instance.
actions/setup-node writes node into a tool-cache shared across concurrent jobs;
with capacity>1 one job execs node while another writes it → "/usr/bin/env:
'node': Text file busy". The catthehacker runner image already ships node 24,
and corepack (bundled) reads each app's packageManager — so setup-node is
unneeded. Removing it eliminates the shared-cache race.
pnpm/action-setup@v4 ran at the repo root (uses: steps ignore
defaults.run.working-directory) where there is no package.json, so it couldn't
read the pnpm version → "No pnpm version specified". Use corepack (bundled with
node) in the install step, which reads each app's own packageManager — matching
the Dockerfiles. Verified in the runner's container: corepack enable + frozen
install succeeds for every app.
pnpm/action-setup ran with no version: `uses:` steps ignore
defaults.run.working-directory, so it executed at the repo root, which has no
package.json (per-app monorepo) → "No pnpm version specified". Pin version: 9
explicitly. Also drop setup-node's `cache: pnpm` — the act_runner cache server
isn't reachable from the DinD job containers, and the install is fast anyway.
Ronni Baslund