0 Fork 0

Files

T

tbekemeyer 18f672ed2a Geteilte Docker-Build-and-Push-Pipeline anlegen

Die bisher in einem einzelnen Projekt liegende Pipeline zieht als
wiederverwendbarer Workflow (on: workflow_call) nach
.gitea/workflows/docker-build-push.yml um.

Inhaltlich geaendert ist genau eine Stelle: Der Eigentuemer des Images
stand als IMAGE_OWNER fest im env-Block des Workflows, wodurch jedes
Image jedes aufrufenden Projekts unter git.jk-dev.de/suer/... gelandet
waere. Er ist jetzt die Eingabe image-owner mit suer als Vorgabewert,
sodass bestehende Aufrufer unveraendert weiterlaufen.

Der Wert kann nicht im env-Block bleiben: env auf Workflow-Ebene wird
ausgewertet, bevor es einen inputs-Kontext gibt. Die Tag-Liste liest ihn
deshalb unmittelbar aus inputs.

Alles Uebrige ist unveraendert uebernommen, samt der Kommentare, die das
Warum erklaeren: 1Password Connect, runs-on, DOCKER_HOST, Diagnoseschritt,
Multi-Arch und Tag-Schema.

Die README dokumentiert Eingaben, ein vollstaendiges Aufrufbeispiel, die
Voraussetzungen im aufrufenden Repository und den Hinweis, auf einen Tag
statt auf @main zu zeigen.

2026-09-30 12:16:34 +00:00

4.0 KiB

Raw Blame History

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

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:

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.

4.0 KiB Raw Blame History