ci: remove Docker GHA cache in CI, lock release cache to fixed scope

[Copilot]

CI Docker builds compete with release builds for the 10 GB GHA cache budget (~500 MB per run for apt/WeasyPrint layers), and PR branches regularly miss the cache anyway due to branch scoping and eviction — making the cache cost-without-benefit.

ci.yml — drop Docker BuildKit GHA cache

• Remove cache-from: type=gha and cache-to: type=gha,mode=max from the Docker build step
• Rename step to "Build formflow image" (no external cache used)
• BuildKit local layer cache still applies within a run; pip install layer is served from it as long as requirements.txt is unchanged
• .venv actions/cache block retained — small (~50 MB), reliable, hash-keyed on requirements*.txt

release.yml — pin BuildKit cache to stable scope

• Add scope=buildkit-main to both cache-from and cache-to

cache-from: type=gha,scope=buildkit-main
cache-to: type=gha,mode=max,scope=buildkit-main

This gives the release cache a fixed key that CI runs can never evict, maximising cache hits on main builds where the cache actually pays off.

Original prompt

Problem

Der aktuelle CI-Workflow (ci.yml) nutzt cache-from: type=gha / cache-to: type=gha,mode=max für den Docker-Build. Das belegt unnötig viel vom 10-GB GitHub Actions Cache-Budget (apt-get-Layer ~200 MB, WeasyPrint + Dependencies ~300 MB) und konkurriert mit dem Release-Workflow um Cache-Platz. Bei PR-Branches kommt es regelmäßig zu Cache-Misses (Branch-Scoping, Eviction), wodurch trotzdem alle Dependencies neu installiert werden – selbst wenn nur ein Bild getauscht wurde (siehe PR #94).

Gewünschte Änderungen

1. ci.yml – Docker BuildKit GHA-Cache entfernen

Im Step "Build formflow image with cache":

• cache-from: type=gha entfernen
• cache-to: type=gha,mode=max entfernen
• Den Step-Namen von "Build formflow image with cache" zu "Build formflow image" ändern (da kein externer Cache mehr genutzt wird)

Docker BuildKit nutzt innerhalb eines Runs trotzdem lokalen Layer-Cache. Der pip install-Layer wird also lokal aus dem Layer-Cache bedient, solange sich requirements.txt nicht geändert hat. Das reicht für CI-Zwecke.

Der bestehende actions/cache-Block für das .venv-Verzeichnis (pip-Pakete für pytest) soll beibehalten werden – er ist klein (~50 MB) und zuverlässig.

2. release.yml – Docker BuildKit GHA-Cache behalten und optimieren

Im Step "Build and push Docker image":

• cache-from ändern zu: type=gha,scope=buildkit-main
• cache-to ändern zu: type=gha,mode=max,scope=buildkit-main

Durch den expliziten scope=buildkit-main wird sichergestellt, dass der Release-Cache konsistent unter einem festen Key liegt und nicht von CI-Runs verdrängt wird.

Dateien die geändert werden müssen

1. .github/workflows/ci.yml – cache-from und cache-to Zeilen im Docker build-push-action Step entfernen, Step-Namen anpassen
2. .github/workflows/release.yml – scope=buildkit-main zu cache-from und cache-to hinzufügen

Erwartetes Ergebnis

• CI-Runs bei Code-Änderungen laufen weiterhin schnell (lokaler Docker Layer-Cache)
• Dependency-Änderungen in CI laufen ungecached durch (akzeptabel, da selten)
• Release-Builds auf main profitieren maximal vom GHA-Cache (mehr Budget, kein Verdrängen durch CI)
• GHA-Cache-Budget wird geschont (kein unnötiges Cachen der Docker-Layer im CI)

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Ich habe im letzten PR nur ein Bild getauscht. Trotzdem wurden alle dependencies aus den requirements neu installiert. War das wirklich notwendig, oder hätten wir das cachen sollen?

Assistant:

Gute Frage! Lass mich mir den letzten PR und die CI/CD-Konfiguration anschauen, um das zu beurteilen.

Assistant: Gute Frage! Kurze Antwort: Nein, die pip-Dependencies wurden bei reinen Bildänderungen nicht unnötig neu installiert. Dein Setup ist bereits gut aufgebaut. Hier die Analyse:

---

✅ CI-Workflow (ci.yml) – Dependencies werden gecacht

Dein CI-Workflow hat bereits einen venv-Cache (Zeilen 34–41):

      - name: Cache virtual environment
        id: cache-venv
        uses: actions/cache@v4
        with:
          path: .venv
          key: venv-${{ runner.os }}-${{ steps.setup-python.outputs.python-version }}-${{ hashFiles('requirements.txt', 'requirements-dev.txt') }}
          restore-keys: |
            venv-${{ runner.os }}-${{ steps.setup-python.outputs.python-version }}-

      - name: Install dependencies
        if: steps.cache-venv.outputs.cache-hit != 'true'
        run: |
          python -m venv .venv
          .venv/bin/pip install --upgrade pip
          .venv/bin/pip install -r requirements-dev.txt

Der Cache-Key basiert auf hashFiles('requirements.txt', 'requirements-dev.txt'). Da du in PR #94 nur src/formflow/static/logo.png geändert hast, bleibt der Hash identisch → Cache-Hit → pip install wird übersprungen. ✅

---

✅ Docker-Build – Ebenfalls gecacht

Der Docker-Build nutzt BuildKit mit GitHub Actions Cache (cache-from: type=gha):

      - name: Build formflow image with cache
        uses: docker/build-push-action@v6
        with:
          context: .
          load: true
          tags: formflow:ci
          cache-from: type=gha
          cache-to: type=gha,mode=max

Und dein Dockerfile ist korrekt in Layers aufgeteilt:

# Layer 2: Python-Dependencies – ändert sich nur bei Dependency-Updates
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Layer 3: Anwendungscode – ändert sich häufig, a...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

<!-- START COPILOT CODING AGENT TIPS -->
---

📱 Kick off Copilot coding agent tasks wherever you are with [GitHub Mobile](https://gh.io/cca-mobile-docs), available on iOS and Android.