photoanalyzer/delivery_backlog/stories/US08-04-gitea-cicd.md

US08-04 — Publish and Deploy from Gitea Actions

Epic: E08

As a release owner, I want main to build, publish, and redeploy the image automatically, so deployment is the same reproducible path every time.

Context

The workflow is adapted from the crowdsec-admin deployment workflow (.gitea/workflows/deploy.yml in that repository): build, log in to the Gitea registry, push, trigger a Portainer webhook, prune. This project needs the same shape plus a test gate, because unlike that project it has a required suite that must not be skipped.

Acceptance criteria

• .gitea/workflows/ contains a test workflow that runs on pull requests and on main, executing the configured required suites, and a deploy workflow that runs only after the tests pass on main and on manual dispatch.
• The deploy workflow publishes to git.domverse-berlin.eu under this project's own image path, tagged latest and the commit SHA, so a rollback is a tag change.
• Registry credentials and the Portainer webhook come from repository secrets; runtime secrets (vision key, Immich key, access secret) stay in the Portainer stack and never enter the repository or the image.
• Redeploy is triggered by webhook and the workflow fails when the webhook call fails.
• Dangling images are pruned; published tags are not.
• A concurrency guard prevents two deploys of different commits overlapping.
• README.md documents the required secrets, the image path, the rollback procedure, and that the stack is managed by Portainer from git.

Automated tests

• Workflow files are validated (syntax and required job/step names) by a repository test so a rename cannot silently disable the test gate.
• A dry-run job builds and pushes to a scratch tag on manual dispatch without touching latest or triggering a redeploy.

Dependencies

• US08-02, US08-03