CI-Templates¶

Die ODI-Service-Repositories bauen ihre Images nach dem gleichen zweistufigen Muster (Dev-Version hochzählen → Image mit Kaniko bauen und pushen, siehe CI/CD- & Flux-Pipeline). Damit dieses Muster nicht in jeder .gitlab-ci.yml kopiert werden muss, liegt es zentral im Repository odi-ci-templates und wird von den Projekten per GitLab-include eingebunden.

Repository

sh/zit/opendata/open-data-infrastruktur/deployment/odi-ci-templates · Lizenz: EUPL-1.2

Verfügbare Templates¶

Beide Templates definieren dieselben zwei Jobs (bump-version → build-image) und unterscheiden sich nur in der Sprache des Versions-Bumps.

Template	Datei	Für	Bump-Skript	Version in
node-dev-build	`templates/node-dev-build.yml`	Node.js-Services	`ci/bump-dev-version.mjs`	`package.json`
python-dev-build	`templates/python-dev-build.yml`	Python-Services	`ci/bump_dev_version.py`	`pyproject.toml`

Die zwei Stages¶

bump-version – erhöht das -dev-N-Suffix der Version, committet es mit [skip ci] zurück auf den Branch und reicht die neue Version über einen dotenv-Report als ${VERSION} an den Build-Job weiter.
build-image – baut das Image mit Kaniko (ohne Docker-Daemon) und pusht es in die IONOS-Registry, getaggt mit der exakten Version und dem beweglichen Tag dev (inkl. Layer-Cache über ${IMAGE}-cache).

Konfigurierbare Variablen¶

Variable	Default	Zweck
`BUMP_SCRIPT_PATH`	`ci/bump-dev-version.mjs` bzw. `ci/bump_dev_version.py`	Pfad zum Bump-Skript im Projekt
`NODE_IMAGE` / `PYTHON_IMAGE`	`node:20.11.1-alpine` / `python:3.12-alpine`	Image für den Bump-Job

Einbindung im Projekt¶

Das Projekt bindet das Template ein und definiert lediglich stages, workflow und die IMAGE-Variable selbst. Die Pipeline baut in die Stage-Registry und nutzt durchgängig die IONOS_STAGE_*-Variablen – ein Mapping auf generische Namen ist nicht nötig:

include:
  - project: 'sh/zit/opendata/open-data-infrastruktur/deployment/odi-ci-templates'
    ref: main
    file: '/templates/node-dev-build.yml'

stages:
  - version
  - build

variables:
  IMAGE: "${IONOS_STAGE_REGISTRY}/${CI_PROJECT_NAME}"

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    - when: never

Zusätzlich muss das passende Bump-Skript (ci/bump-dev-version.mjs bzw. ci/bump_dev_version.py) im Projekt liegen.

Benötigte CI/CD-Variablen (Settings → CI/CD → Variables)

IONOS_STAGE_REGISTRY · IONOS_STAGE_REGISTRY_USER · IONOS_STAGE_REGISTRY_PASSWORD (masked) · CI_PUSH_TOKEN (masked, write_repository).

Projekte, die die Templates nutzen¶

Projekt	Genutztes Template
`odi-ckan-service`	node-dev-build
`odi-metadata-service`	node-dev-build
`odi-staging-backend`	node-dev-build
`odi-schema-staging-frontend`	node-dev-build
`odi-frictionless-backend`	python-dev-build

Noch nicht migriert

Diese Projekte folgen demselben Muster, halten die Pipeline aber (noch) inline in ihrer eigenen .gitlab-ci.yml, statt das geteilte Template einzubinden:

odi-schema-backend – inline Node-Pipeline (identisch zu node-dev-build).
open-data-web – inline Node-Pipeline, baut jedoch zwei Images (Frontend + NestJS) über einen gemeinsamen .kaniko-build-Job; ein direkter Umstieg auf das Single-Image-Template ist daher nicht 1:1 möglich.

Das Doku-Repo odi-documentation hat bewusst eine andere Pipeline: Es baut keine Container, sondern veröffentlicht via mkdocs build nach GitLab Pages.