Geteilte Docker-Build-and-Push-Pipeline anlegen #1

New Issue

2026-09-30T14:12:18+02:00

bk-dev-bot commented

2026-09-30 14:12:18 +02:00

Dieses Repository soll die geteilten CI/CD-Bausteine der Instanz aufnehmen. Den Anfang macht die bestehende Build-and-Push-Pipeline für Docker-Images, die bisher in einem einzelnen Projekt lag.

Das Repository enthält bislang nur eine README.

Aufgabe

Die vorhandene Pipeline als wiederverwendbaren Workflow (on: workflow_call) unter .gitea/workflows/ ablegen, sodass mehrere Projekte sie aufrufen können:

jobs:
  image:
    uses: workflow-util/pipelines/.gitea/workflows/<datei>.yml@<tag>
    with:
      container-name: bk-dev-website
      # ...
    secrets: inherit

Die eine Änderung, die wirklich nötig ist

Der Workflow verdrahtet den Eigentümer des Images fest:

env:
  IMAGE_OWNER: suer

Unverändert übernommen landete jedes Image unter git.jk-dev.de/suer/…, unabhängig davon, welches Projekt die Pipeline aufruft. Das ist die einzige Stelle, die einer Wiederverwendung über mehrere Eigentümer hinweg tatsächlich im Weg steht.

Sie muss eine Eingabe werden — mit suer als Vorgabewert, damit bestehende Aufrufer unverändert weiterlaufen.

Unverändert übernehmen

Alles andere bleibt, wie es ist. Insbesondere:

die Beschaffung der Zugangsdaten über 1Password Connect (OP_CONNECT_HOST als Variable, OP_CONNECT_TOKEN als Secret),
runs-on: [ ubuntu-docker ],
DOCKER_HOST aus vars.DOCKER_HOST wegen des möglicherweise rootless laufenden Runner-Daemons,
der Diagnoseschritt, der den tatsächlich ankommenden Docker-Socket ausgibt,
Multi-Arch mit linux/amd64,linux/arm64,
das Tag-Schema.

Die vorhandenen Kommentare erklären jeweils das Warum und sollen erhalten bleiben.

Versionierung

Aufrufer sollen auf einen Tag zeigen, nicht auf @main. Sonst ändert eine Anpassung hier unangekündigt das Verhalten aller Projekte — und der Fehler zeigt sich dort, wo niemand etwas geändert hat.

Daher nach dem Zusammenführen einen Tag setzen und in der README dokumentieren, worauf Aufrufer zeigen sollen.

Erster Abnehmer

bekemeyer-klein/bk-dev-website — dort unter Issue #20 verfolgt. Die projektseitigen Bausteine (Dockerfile, Standalone-Build) entstehen dort parallel.

Beim Anlegen des Aufrufs dann beachten: Das Projekt nutzt das Versionsschema YYYY.MM.X. Es bildet sich auf die vier Versionseingaben ab (Major 2026, Minor 09, Patch 1), erzeugt dabei aber die mitwandernden Tags :2026 und :2026.09, die bei einem Kalenderschema wenig Nutzen haben, sowie :2026.09.1 doppelt. Das ist kein Fehler, aber ein Grund, die Tag-Liste später eventuell konfigurierbar zu machen.

Dieses Repository soll die geteilten CI/CD-Bausteine der Instanz aufnehmen. Den Anfang macht die bestehende Build-and-Push-Pipeline für Docker-Images, die bisher in einem einzelnen Projekt lag. Das Repository enthält bislang nur eine README. ## Aufgabe Die vorhandene Pipeline als wiederverwendbaren Workflow (`on: workflow_call`) unter `.gitea/workflows/` ablegen, sodass mehrere Projekte sie aufrufen können: ```yaml jobs: image: uses: workflow-util/pipelines/.gitea/workflows/<datei>.yml@<tag> with: container-name: bk-dev-website # ... secrets: inherit ``` ## Die eine Änderung, die wirklich nötig ist Der Workflow verdrahtet den Eigentümer des Images fest: ```yaml env: IMAGE_OWNER: suer ``` Unverändert übernommen landete jedes Image unter `git.jk-dev.de/suer/…`, unabhängig davon, welches Projekt die Pipeline aufruft. Das ist die einzige Stelle, die einer Wiederverwendung über mehrere Eigentümer hinweg tatsächlich im Weg steht. Sie muss eine Eingabe werden — mit `suer` als Vorgabewert, damit bestehende Aufrufer unverändert weiterlaufen. ## Unverändert übernehmen Alles andere bleibt, wie es ist. Insbesondere: - die Beschaffung der Zugangsdaten über 1Password Connect (`OP_CONNECT_HOST` als Variable, `OP_CONNECT_TOKEN` als Secret), - `runs-on: [ ubuntu-docker ]`, - `DOCKER_HOST` aus `vars.DOCKER_HOST` wegen des möglicherweise rootless laufenden Runner-Daemons, - der Diagnoseschritt, der den tatsächlich ankommenden Docker-Socket ausgibt, - Multi-Arch mit `linux/amd64,linux/arm64`, - das Tag-Schema. Die vorhandenen Kommentare erklären jeweils das Warum und sollen erhalten bleiben. ## Versionierung Aufrufer sollen auf einen **Tag** zeigen, nicht auf `@main`. Sonst ändert eine Anpassung hier unangekündigt das Verhalten aller Projekte — und der Fehler zeigt sich dort, wo niemand etwas geändert hat. Daher nach dem Zusammenführen einen Tag setzen und in der README dokumentieren, worauf Aufrufer zeigen sollen. ## Erster Abnehmer `bekemeyer-klein/bk-dev-website` — dort unter Issue #20 verfolgt. Die projektseitigen Bausteine (Dockerfile, Standalone-Build) entstehen dort parallel. Beim Anlegen des Aufrufs dann beachten: Das Projekt nutzt das Versionsschema `YYYY.MM.X`. Es bildet sich auf die vier Versionseingaben ab (Major `2026`, Minor `09`, Patch `1`), erzeugt dabei aber die mitwandernden Tags `:2026` und `:2026.09`, die bei einem Kalenderschema wenig Nutzen haben, sowie `:2026.09.1` doppelt. Das ist kein Fehler, aber ein Grund, die Tag-Liste später eventuell konfigurierbar zu machen.

bk-dev-bot referenced a pull request that will close this issue

2026-09-30 14:17:02 +02:00

Geteilte Docker-Build-and-Push-Pipeline anlegen #2

jklein closed this issue

2026-09-30 16:11:06 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: workflow-util/pipelines#1