Forgejo Pipelines · Workshop Lektion 4 / Variablen & DRY

env, vars & DRY-Pipelines

Werte einmal festlegen, überall nutzen – und ${{ … }} endlich verstehen.

Warum das zählt
Sobald eine Pipeline wächst, wiederholen sich Image-Namen, Versionen und Flags. Wer Variablen und Ausdrücke beherrscht, hält die Pipeline wartbar – und versteht, woher Werte zur Laufzeit kommen.

Drei Quellen für Werte

QuelleWasZugriff
envIm Workflow definierte Umgebungsvariablen$NAME oder ${{ env.NAME }}
varsNicht-geheime Repo-/Org-Variablen (UI)${{ vars.NAME }}
secretsGeheimnisse (UI), maskiert in Logs${{ secrets.NAME }}

env auf drei Ebenen

.forgejo/workflows/ci.yaml
on: [push]
env:                          # für ALLE Jobs
  PYTHON_VERSION: "3.12"

jobs:
  test:
    runs-on: docker
    container: python:${{ env.PYTHON_VERSION }}-slim
    env:                      # nur für diesen Job
      PYTEST_ADDOPTS: "-q"
    steps:
      - uses: actions/checkout@v4
      - run: pytest
        env:                  # nur für diesen Step
          COVERAGE: "1"

Engere Ebenen gewinnen: Step-env überschreibt Job-env überschreibt Workflow-env.

Shell-Variable oder Ausdruck?

Die zwei Welten von Werten ${{ … }} wird vor der Ausführung von Forgejo ersetzt (im YAML-Wert). $NAME löst die Shell zur Laufzeit auf (im run:). Für Umgebungsvariablen sind beide okay – aber Kontexte wie ${{ secrets.X }} gibt es nur in der ${{ }}-Form.

DRY: Wiederholung vermeiden

Forgejo hat kein GitLab-extends. Stattdessen helfen YAML-Anker für kleine Wiederholungen – und für echte Wiederverwendung über Workflows hinweg gibt es reusable workflows (Lektion 11): 

defaults:                     # gemeinsame run-Einstellungen
  run:
    shell: bash

jobs:
  test:
    runs-on: docker
    container: &img python:3.12-slim   # Anker definieren
  lint:
    runs-on: docker
    container: *img                  # Anker wiederverwenden

Parallelen: GitLab CI ↔ Forgejo Actions

GitLab CI

variables: global/job

Wiederverwenden via extends / !reference

$CI_…-Variablen

Forgejo Actions

env: + vars/secrets-Kontext

Wiederverwenden via YAML-Anker / reusable workflows

$FORGEJO_…-Variablen

Übungen für Teilnehmende

Übung 1 · Lesen

Frage: Workflow-env setzt LOG=info, der Step-env setzt LOG=debug. Welchen Wert sieht der Befehl im Step?

Lösung anzeigen

debug – die engste Ebene (Step) gewinnt.

Übung 2 · Selbst schreiben

Aufgabe: Lege eine Repo-Variable IMAGE_TAG an (UI) und nutze sie im Workflow als Teil eines Echo-Befehls.

Lösung anzeigen 
      - run: echo "Baue Tag ${{ vars.IMAGE_TAG }}"

vars.* kommt aus Repo & Settings → Actions → Variables. Für Geheimes nimmst du secrets.* – sonst identisch.

Kurz prüfen (aus dem Kopf)

Womit liest du ein Secret in einem Workflow?

Welche env-Ebene hat Vorrang?

Primärquelle zum Lesen Forgejo Docs – Reference, Abschnitte env und „Contexts" (vars, secrets, env).
Ich bin dein Teacher. Verwirrt von $NAME vs. ${{ }}? Frag im Chat – mit einem konkreten Beispiel wird der Unterschied schnell klar.
← Lektion 3 · Artifacts & Cache Lektion 5 · Trigger-Events & Bedingungen →