Add Gitea Actions workflow to build and push the image on main

.gitea/workflows/deploy.yml

@@ -0,0 +1,54 @@
+# Builds the production image on every push to main and pushes it to the Gitea
+# registry, tagged with :latest AND the short commit SHA (for rollback) -- the
+# same tagging scheme as scripts/release.sh, but run by the act_runner instead
+# of by hand.
+#
+# It does NOT deploy: pulling and starting the new :latest on Unraid stays a
+# manual, deliberate step (Compose Down/Up). Auto-deploy via Watchtower is an
+# open item in docs/deployment.md and needs a health gate first, so a broken
+# page can never go live unnoticed.
+#
+# Required repository secrets (Gitea -> repo -> Settings -> Actions -> Secrets):
+#   REGISTRY_USER   the registry username (e.g. Tom)
+#   REGISTRY_TOKEN  a Gitea access token with package:write -- NOT the password
+
+name: Build and push image
+
+on:
+  push:
+    branches: [main]
+
+env:
+  IMAGE: gitea.anticarnist.de/tom/elternbeirat
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out the source
+        uses: actions/checkout@v4
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Log in to the Gitea registry
+        uses: docker/login-action@v3
+        with:
+          registry: gitea.anticarnist.de
+          username: ${{ secrets.REGISTRY_USER }}
+          password: ${{ secrets.REGISTRY_TOKEN }}
+
+      # The short SHA names the image content unambiguously and never moves,
+      # so it is the stable handle for a rollback.
+      - name: Compute the short commit SHA
+        id: sha
+        run: echo "short=$(git rev-parse --short HEAD)" >> "$GITHUB_OUTPUT"
+
+      - name: Build and push (:latest and :<sha>)
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          tags: |
+            ${{ env.IMAGE }}:latest
+            ${{ env.IMAGE }}:${{ steps.sha.outputs.short }}

docs/deployment.md

@@ -170,13 +170,50 @@ Which SHA tags are in the registry is shown by Gitea under
 
 ---
 
-## Open automation (later)
+## Automation
 
-- `.gitea/workflows/deploy.yml`: build and push on push to `main`.
-- Two known pitfalls: the `act_runner` needs Docker socket access; the registry
-  needs the `write:package` token, not the login password.
-- Redeploy via Watchtower **label-scoped**, otherwise it updates the entire
-  home-lab inventory.
-- **Encrypt the registry token on Unraid:** currently it sits in plain text in
-  `/root/.docker/config.json`. Set up a credential helper later, so that the
-  plain-text warning from `docker login` disappears.
+### Build and push (done)
+
+`.gitea/workflows/deploy.yml` builds the image on every push to `main` and pushes
+it to the registry, tagged `:latest` **and** `:<short-sha>` — the same scheme as
+`scripts/release.sh`, just run by the `act_runner` instead of by hand. It does
+**not** deploy; pulling and starting the new `:latest` on Unraid stays a manual,
+deliberate step (see "Pull and start again on Unraid" above).
+
+Requires two repository secrets (Gitea → repo → **Settings** → **Actions** →
+**Secrets**):
+
+- `REGISTRY_USER` — the registry username (e.g. `Tom`).
+- `REGISTRY_TOKEN` — a Gitea access token with **`package: write`**, *not* the
+  login password.
+
+Two known pitfalls: the `act_runner` needs Docker socket access to build, and it
+must offer the `ubuntu-latest` label the workflow asks for. To check the runner:
+Gitea → repo (or site admin) → **Settings** → **Actions** → **Runners** — it
+should be listed as **online** with a label set that includes `ubuntu-latest`.
+
+### Auto-deploy via Watchtower (open — needs a health gate first)
+
+Automatically rolling out `:latest` the moment it lands in the registry is
+tempting, but **not** something to switch on blindly: a build can be green and
+still serve a broken page (a bad content file, a runtime-only culture crash like
+the de-DE one). Auto-deploy without a gate would push that live **unnoticed**.
+
+So before turning this on, decide the gate:
+
+- The container must prove itself **healthy** before it replaces the running one
+  — but the chiseled image has no shell, so a `HEALTHCHECK` with `curl`/`sh` does
+  not work inside it. The check has to come from outside (e.g. an external probe
+  hitting a known route, or a compose-level check from a sidecar).
+- Watchtower must be **label-scoped** to *only* the `eb-web` container, otherwise
+  it updates the entire home-lab inventory.
+- Keep a fast **rollback**: pin `:<sha>` in the Unraid compose and bring it back
+  up (see "Rollback" above).
+
+Until that gate exists, deployment stays manual on purpose.
+
+### Encrypt the registry token on Unraid (open)
+
+Currently the token sits in plain text in `/root/.docker/config.json`. Set up a
+credential helper later, so that the plain-text warning from `docker login`
+disappears.