devops: extract composite action for obs stack deploy steps #603

New Issue

marcel · 2026-05-16T09:20:25+02:00

marcel commented

2026-05-16 09:20:25 +02:00

Context

nightly.yml and release.yml both contain four identical obs-deploy steps:

Deploy observability configs — rsync to /opt/familienarchiv/, write obs-secrets.env
Validate observability compose config — docker compose config --quiet
Start observability stack — docker compose up -d --wait
Assert observability stack health — loop over the 4 healthchecked services

The only difference between the two workflows is:

Which secret names are used (STAGING_* vs PROD_*)
Which POSTGRES_HOST value is written (archiv-staging-db-1 vs archiv-production-db-1)

This duplication means any future fix (e.g. adding a new healthchecked service, changing the rsync flags) must be applied in two places. The # Keep in sync with nightly.yml comments are a smell that a composite action is the right fix.

Proposal

Create a Gitea composite action at .gitea/actions/deploy-obs/action.yml with inputs:

Input	Description
`grafana_admin_password`	Secret value
`glitchtip_secret_key`	Secret value
`postgres_password`	Secret value
`postgres_host`	e.g. `archiv-staging-db-1`

The action runs all four steps internally. Both workflows call it once:

- uses: ./.gitea/actions/deploy-obs
  with:
    grafana_admin_password: ${{ secrets.GRAFANA_ADMIN_PASSWORD }}
    glitchtip_secret_key: ${{ secrets.GLITCHTIP_SECRET_KEY }}
    postgres_password: ${{ secrets.STAGING_POSTGRES_PASSWORD }}
    postgres_host: archiv-staging-db-1

Acceptance criteria

.gitea/actions/deploy-obs/action.yml implements all 4 steps as a composite action
nightly.yml replaces its 4 obs steps with a single uses: call
release.yml replaces its 4 obs steps with a single uses: call
The # Keep in sync with nightly.yml comments are removed (no longer needed)
Both pipelines pass on a test run after the change

## Context `nightly.yml` and `release.yml` both contain four identical obs-deploy steps: 1. **Deploy observability configs** — `rsync` to `/opt/familienarchiv/`, write `obs-secrets.env` 2. **Validate observability compose config** — `docker compose config --quiet` 3. **Start observability stack** — `docker compose up -d --wait` 4. **Assert observability stack health** — loop over the 4 healthchecked services The only difference between the two workflows is: - Which secret names are used (`STAGING_*` vs `PROD_*`) - Which `POSTGRES_HOST` value is written (`archiv-staging-db-1` vs `archiv-production-db-1`) This duplication means any future fix (e.g. adding a new healthchecked service, changing the rsync flags) must be applied in two places. The `# Keep in sync with nightly.yml` comments are a smell that a composite action is the right fix. ## Proposal Create a [Gitea composite action](https://docs.gitea.com/usage/actions/composite-action) at `.gitea/actions/deploy-obs/action.yml` with inputs: | Input | Description | |---|---| | `grafana_admin_password` | Secret value | | `glitchtip_secret_key` | Secret value | | `postgres_password` | Secret value | | `postgres_host` | e.g. `archiv-staging-db-1` | The action runs all four steps internally. Both workflows call it once: ```yaml - uses: ./.gitea/actions/deploy-obs with: grafana_admin_password: ${{ secrets.GRAFANA_ADMIN_PASSWORD }} glitchtip_secret_key: ${{ secrets.GLITCHTIP_SECRET_KEY }} postgres_password: ${{ secrets.STAGING_POSTGRES_PASSWORD }} postgres_host: archiv-staging-db-1 ``` ## Acceptance criteria - [ ] `.gitea/actions/deploy-obs/action.yml` implements all 4 steps as a composite action - [ ] `nightly.yml` replaces its 4 obs steps with a single `uses:` call - [ ] `release.yml` replaces its 4 obs steps with a single `uses:` call - [ ] The `# Keep in sync with nightly.yml` comments are removed (no longer needed) - [ ] Both pipelines pass on a test run after the change

marcel added the P2-medium devops labels 2026-05-16 09:20:37 +02:00

marcel referenced this issue from a commit

2026-05-16 09:35:45 +02:00

ci(obs): reference #603 in keep-in-sync comments; add obs-glitchtip to health assertion

marcel referenced this issue

2026-05-16 09:43:36 +02:00

fix(obs): Tempo processors schema fix + configurable Postgres host and Grafana port #602

marcel referenced this issue

2026-05-16 09:44:26 +02:00

fix(obs): Tempo processors schema fix + configurable Postgres host and Grafana port #602

Sign in to join this conversation.