Container-Image bauen & pushen

Aus der Tasks-API wird ein Image – in der Forgejo-eigenen Container Registry.

Warum das zählt
Tests sind grün – jetzt soll daraus ein deploybares Container-Image entstehen und in einer Registry landen. Forgejo bringt eine eigene Container Registry mit. Das Bauen und Pushen hat ein paar Forgejo-Eigenheiten, an denen viele zuerst scheitern – die nehmen wir hier vorweg.

Der Image-Name folgt einem festen Schema

{registry}/{owner}/{image} Die Registry ist die Domain deiner Forgejo-Instanz. Ein Image heisst git.example.com/owner/image – z. B. git.example.com/team/tasks-api. Owner ist der Nutzer oder die Organisation. Anders als bei Docker Hub kannst du nicht in einen beliebigen neuen Pfad pushen, ohne dass der Namespace existiert.

Login + Build + Push

.forgejo/workflows/release.yaml (Auszug)

  image:
    runs-on: docker
    needs: [test]
    if: ${{ forgejo.ref == 'refs/heads/main' }}
    steps:
      - uses: actions/checkout@v4
      - uses: https://code.forgejo.org/docker/login-action@v3
        with:
          registry: git.example.com
          username: ${{ secrets.REGISTRY_USER }}
          password: ${{ secrets.REGISTRY_TOKEN }}
      - uses: https://code.forgejo.org/docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: git.example.com/team/tasks-api:${{ forgejo.sha }}

Der automatische Token kann NICHT pushen FORGEJO_TOKEN/GITHUB_TOKEN reicht zum Lesen des Repos, aber nicht zum Pushen von Paketen/Images. Lege ein Personal Access Token (oder Org-Token) mit Paket-Schreibrechten an und hinterlege es als Secret (z. B. REGISTRY_TOKEN). Genau hier bleibt der erste Push-Versuch fast immer hängen.

Docker im Job build-push-action braucht eine funktionierende Docker-Umgebung im Runner. Je nach Runner-Setup heisst das Docker-in-Docker (privilegiert) oder ein gemounteter Docker-Socket. Steht kein Docker bereit, sind Alternativen wie buildah/kaniko üblich. Das ist Runner-Konfiguration – im Zweifel mit der Admin-Person klären.

Parallelen: GitLab CI ↔ Forgejo Actions

GitLab CI

$CI_REGISTRY_IMAGE vordefiniert

$CI_REGISTRY_PASSWORD pusht out-of-the-box

DinD-Service üblich

Forgejo Actions

Image-Name selbst zusammensetzen

Eigenes PAT-Secret zum Pushen nötig ★

docker/*-Actions + Docker im Runner

Übungen für Teilnehmende

Übung 1 · Fehler erklären

Frage: Ein Workflow nutzt zum Login ${{ secrets.GITHUB_TOKEN }} und scheitert beim Push mit „unauthorized". Warum?

Lösung anzeigen

Der automatische Token darf keine Pakete schreiben. Du brauchst ein eigenes PAT mit Paket-Schreibrecht als Secret.

Übung 2 · Selbst schreiben

Aufgabe: Tagge das Image zusätzlich mit latest, wenn auf main gebaut wird.

Lösung anzeigen

          tags: |
            git.example.com/team/tasks-api:${{ forgejo.sha }}
            git.example.com/team/tasks-api:latest

Mehrere Tags als YAML-Mehrzeiler. Den main-Filter erledigt schon das if: am Job.

Kurz prüfen (aus dem Kopf)

Womit authentifiziert sich der Push in die Forgejo-Registry?

Mit einem eigenen Token-Secret
Mit dem automatischen Job-Token
Ganz ohne Login auf main

Wie ist ein Image in der Forgejo-Registry benannt?

Als {registry}/{owner}/{image}
Als {image} ohne Präfix
Als docker.io/{image}

Primärquelle zum Lesen Forgejo Docs – Container Registry (Login, Naming, Tokens).

Ich bin dein Teacher. „unauthorized" oder kein Docker im Runner? Schick mir die Fehlermeldung – wir trennen Token-Problem von Runner-Setup.

← Lektion 7 · services – Postgres Lektion 9 · strategy:matrix →