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

This commit is contained in:
tleininger committed 2026-09-22 08:35:33 +02:00
1 parent 14f3d751c7
commit af051ef4bd
2 files changed
+100 -9

No files matched your search

+46 -9
View File
@@ -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.