# US08-04 — Publish and Deploy from Gitea Actions

Epic: [E08](../E08-container-deployment.md)

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