US08-04 — Publish and Deploy from Gitea Actions #90

New Issue

domverse · 2026-08-17T21:11:36+02:00

domverse commented

2026-08-17 21:11:36 +02:00

Source specification: 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

Source specification: [delivery_backlog/stories/US08-04-gitea-cicd.md](https://git.domverse-berlin.eu/domverse/photoanalyzer/src/branch/main/delivery_backlog/stories/US08-04-gitea-cicd.md) # US08-04 — Publish and Deploy from Gitea Actions Epic: [E08](https://git.domverse-berlin.eu/domverse/photoanalyzer/src/branch/main/delivery_backlog/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