# pipelines

Geteilte CI/CD-Bausteine für die Gitea-Instanz `git.jk-dev.de`. Die Workflows
hier werden nicht selbst ausgelöst, sondern von anderen Repositories über
`uses:` aufgerufen (`on: workflow_call`).

## Bausteine

### `.gitea/workflows/docker-build-push.yml`

Baut ein Docker-Image und schiebt es als Multi-Arch-Manifest
(`linux/amd64,linux/arm64`) in die Registry `git.jk-dev.de`. Läuft auf einem
Runner mit dem Label `ubuntu-docker`.

Gepusht wird unter fünf Tags:

```
git.jk-dev.de/<image-owner>/<container-name>:latest
git.jk-dev.de/<image-owner>/<container-name>:<version-number>
git.jk-dev.de/<image-owner>/<container-name>:<major>
git.jk-dev.de/<image-owner>/<container-name>:<major>.<minor>
git.jk-dev.de/<image-owner>/<container-name>:<major>.<minor>.<patch>
```

Der Checkout holt Submodule mit; die Zugangsdaten dafür und für die Registry
kommen zur Laufzeit aus 1Password Connect.

#### Eingaben

| Eingabe                | Pflicht | Vorgabe                   | Bedeutung |
| ---------------------- | ------- | ------------------------- | --------- |
| `version-number`       | ja      | —                         | Vollständige Version, wird als Tag gesetzt |
| `version-number-major` | ja      | —                         | Major-Anteil für die mitwandernden Tags |
| `version-number-minor` | ja      | —                         | Minor-Anteil |
| `version-number-patch` | ja      | —                         | Patch-Anteil |
| `container-name`       | ja      | —                         | Name des Images |
| `dockerfile`           | ja      | —                         | Pfad zum Dockerfile |
| `docker-context`       | ja      | —                         | Build-Kontext |
| `image-owner`          | nein    | `suer`                    | Eigentümer-Segment des Images, also der mittlere Teil von `<registry>/<owner>/<name>` |
| `timeout-minutes`      | nein    | `45`                      | Harte Grenze für den Build-Job |
| `platforms`            | nein    | `linux/amd64,linux/arm64` | Zielplattformen der Manifest-Liste |
| `build-args`           | nein    | —                         | Zusätzliche Build-Argumente, ein `NAME=wert` je Zeile |

#### Aufrufbeispiel

```yaml
jobs:
  image:
    uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@v1
    with:
      version-number: 2026.09.1
      version-number-major: '2026'
      version-number-minor: '09'
      version-number-patch: '1'
      container-name: bk-dev-website
      dockerfile: ./Dockerfile
      docker-context: .
      image-owner: bekemeyer-klein
    secrets: inherit
```

`secrets: inherit` ist notwendig — der Workflow braucht `OP_CONNECT_TOKEN` aus
dem aufrufenden Repository.

#### Voraussetzungen im aufrufenden Repository

| Name               | Art      | Zweck |
| ------------------ | -------- | ----- |
| `OP_CONNECT_HOST`  | Variable | Adresse des 1Password-Connect-Servers im Cluster |
| `OP_CONNECT_TOKEN` | Secret   | Zugang zu diesem Connect-Server |
| `DOCKER_HOST`      | Variable | Nur nötig, wenn der Runner-Daemon rootless läuft und sein Socket nicht unter `/var/run/docker.sock` liegt (dann z. B. `unix:///run/user/1000/docker.sock`). Ist die Variable nicht gesetzt, nutzt Docker seinen Default. |

Die eigentlichen Zugänge für Checkout und Registry liegen in 1Password
(`GitHub-Actions/jlab-git-checkout-token`, `GitHub-Actions/jlab-registry-access`)
und müssen in Gitea nicht hinterlegt werden.

## Auf einen Tag zeigen, nicht auf `@main`

Aufrufe bitte immer an einen Tag binden:

```yaml
uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@v1   # so
uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@main # nicht so
```

Mit `@main` ändert jede Anpassung hier unangekündigt das Verhalten sämtlicher
Projekte — und der Fehler zeigt sich dann dort, wo niemand etwas geändert hat.
Ein Tag macht das Übernehmen einer neuen Fassung zu einer bewussten Entscheidung
im jeweiligen Projekt.

Änderungen hier bekommen deshalb einen neuen Tag. Bricht eine Änderung
bestehende Aufrufe, wird der Major-Anteil erhöht.