Prüfmodus ohne Push kann keine privaten Submodule klonen #3

New Issue

2026-09-30T16:02:43+02:00

bk-dev-bot commented

2026-09-30 16:02:43 +02:00

Mit #2 bekommt docker-build-push.yml die Eingabe push. Bei push: false
wird der 1Password-Schritt übersprungen — so gewollt, damit ein reiner Prüflauf
ohne Zugangsdaten auskommt.

Der Checkout-Token stammt aber aus demselben Schritt. Ohne Push fällt
actions/checkout deshalb auf den Standard-Token des Jobs zurück. Der genügt
für das ausführende Repository, nicht für Submodule in eigenen privaten
Repositories — deren Klon scheitert mit Repository not found.

Folge: Projekte mit privaten Submodulen können push: false nicht nutzen.
Der Prüfmodus steht damit ausgerechnet den Projekten nicht zur Verfügung, deren
Build am ehesten etwas zu prüfen hätte.

Das ist in #2 dokumentiert (Kommentar am 1Password-Schritt, hervorgehobener
Hinweis in der README), aber nicht gelöst. Dieses Issue hält den offenen Punkt
fest, damit er nicht nur im Fließtext der README steht.

Denkbare Wege

Den 1Password-Schritt zweiteilen. Ein Schritt holt nur den
Checkout-Token und läuft immer, ein zweiter holt die Registry-Zugangsdaten
und läuft nur beim Push. Nächstliegend, hält den Prüfmodus aber nicht mehr
secret-frei — OP_CONNECT_TOKEN und secrets: inherit blieben nötig.
Eine Eingabe submodules (Vorgabe true). Projekte ohne Submodule
schalten ab und brauchen im Prüfmodus gar keinen Token. Löst das Problem
nicht, macht es aber sichtbar und vermeidet den nutzlosen Klonversuch.
Eine eigene Eingabe checkout-token, die der Aufrufer selbst besorgt.
Verschiebt die Frage nur nach außen.

Die Entscheidung gehört zusammen mit dem ersten Aufrufer getroffen, der
tatsächlich private Submodule hat. Vorher ist sie Spekulation.

Mit #2 bekommt `docker-build-push.yml` die Eingabe `push`. Bei `push: false` wird der 1Password-Schritt übersprungen — so gewollt, damit ein reiner Prüflauf ohne Zugangsdaten auskommt. Der Checkout-Token stammt aber aus **demselben** Schritt. Ohne Push fällt `actions/checkout` deshalb auf den Standard-Token des Jobs zurück. Der genügt für das ausführende Repository, nicht für Submodule in eigenen privaten Repositories — deren Klon scheitert mit `Repository not found`. **Folge:** Projekte mit privaten Submodulen können `push: false` nicht nutzen. Der Prüfmodus steht damit ausgerechnet den Projekten nicht zur Verfügung, deren Build am ehesten etwas zu prüfen hätte. Das ist in #2 dokumentiert (Kommentar am 1Password-Schritt, hervorgehobener Hinweis in der README), aber nicht gelöst. Dieses Issue hält den offenen Punkt fest, damit er nicht nur im Fließtext der README steht. ## Denkbare Wege 1. **Den 1Password-Schritt zweiteilen.** Ein Schritt holt nur den Checkout-Token und läuft immer, ein zweiter holt die Registry-Zugangsdaten und läuft nur beim Push. Nächstliegend, hält den Prüfmodus aber nicht mehr secret-frei — `OP_CONNECT_TOKEN` und `secrets: inherit` blieben nötig. 2. **Eine Eingabe `submodules`** (Vorgabe `true`). Projekte ohne Submodule schalten ab und brauchen im Prüfmodus gar keinen Token. Löst das Problem nicht, macht es aber sichtbar und vermeidet den nutzlosen Klonversuch. 3. **Eine eigene Eingabe `checkout-token`**, die der Aufrufer selbst besorgt. Verschiebt die Frage nur nach außen. Die Entscheidung gehört zusammen mit dem ersten Aufrufer getroffen, der tatsächlich private Submodule hat. Vorher ist sie Spekulation.

bk-dev-bot commented

2026-09-30 19:48:35 +02:00

Nicht mehr theoretisch — der Checkout-Token blockiert den ersten echten Abnehmer

Dieses Issue beschrieb bisher einen Vorbehalt: Im Modus ohne Push steht der Checkout-Token nicht zur Verfügung, private Submodule ließen sich nicht klonen. Die Wirklichkeit ist ungünstiger — im Modus mit Push scheitert der Checkout ganz, wenn der 1Password-Token keinen Zugriff auf das aufrufende Repository hat.

Gemessen an Lauf 278 von bekemeyer-klein/bk-dev-website:

[command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune … origin +45aee1d…
remote: Repository not found
fatal: repository 'http://…/bekemeyer-klein/bk-dev-website/' not found
The process '/usr/bin/git' failed with exit code 128

Dreimal wiederholt, dann Abbruch. Der Job scheitert vor dem Bau; --push und der Registry-Login kommen gar nicht mehr zum Zug.

Repository not found ist die Antwort, die Gitea bei fehlender Berechtigung auf ein privates Repository gibt — der Token existiert, er darf nur nicht.

Die Asymmetrie ist das Problem

Modus	Checkout nutzt	Ergebnis bei `bk-dev-website`
`push: 'false'`	Job-Token (Rückfall)	funktioniert
`push: 'true'`	`jlab-git-checkout-token` aus 1Password	scheitert

Ob der Checkout funktioniert, hängt damit daran, ob gepusht wird. Das ist kein naheliegender Zusammenhang, und er kostet Zeit beim Suchen: Der Fehler sieht nach einem Rechteproblem am Repository aus, ist aber eines am geteilten Token.

Lösungsrichtungen

1. Den Token berechtigen — jlab-git-checkout-token Zugriff auf das aufrufende Repository geben. Schnell, aber es skaliert schlecht: Jedes neue Projekt braucht die Freigabe, und der Token sammelt mit der Zeit Rechte auf alles.

2. Den Checkout-Token opt-in machen (empfohlen). Der Normalfall ist ein Repository ohne private Submodule; dort genügt der Job-Token. Eine Eingabe wie private-submodules: 'false' (Vorgabe) würde steuern, ob der Token überhaupt geholt und verwendet wird. Projekte mit privaten Submodulen setzen sie ausdrücklich.

Damit verschwindet zugleich die im Ursprungstext beschriebene Einschränkung: Der Prüfmodus wäre dann nicht mehr schlechter gestellt als der Push-Modus, weil beide denselben Weg nehmen.

3. Den 1Password-Schritt zweiteilen — Checkout-Token immer holen, Registry-Zugang nur beim Push. Behebt die Asymmetrie, lässt aber Lösungsrichtung 1 als Voraussetzung bestehen.

Empfehlung

Lösungsrichtung 2. Sie macht den Baustein für beliebige Repositories nutzbar, ohne dass ein geteilter Token überall Zugriff braucht — und sie folgt dem Grundsatz, dass der Sonderfall die Ausnahme sein sollte, nicht die Vorgabe.

## Nicht mehr theoretisch — der Checkout-Token blockiert den ersten echten Abnehmer Dieses Issue beschrieb bisher einen Vorbehalt: Im Modus ohne Push steht der Checkout-Token nicht zur Verfügung, private Submodule ließen sich nicht klonen. Die Wirklichkeit ist ungünstiger — **im Modus *mit* Push scheitert der Checkout ganz**, wenn der 1Password-Token keinen Zugriff auf das aufrufende Repository hat. Gemessen an Lauf 278 von `bekemeyer-klein/bk-dev-website`: ``` [command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune … origin +45aee1d… remote: Repository not found fatal: repository 'http://…/bekemeyer-klein/bk-dev-website/' not found The process '/usr/bin/git' failed with exit code 128 ``` Dreimal wiederholt, dann Abbruch. Der Job scheitert **vor** dem Bau; `--push` und der Registry-Login kommen gar nicht mehr zum Zug. `Repository not found` ist die Antwort, die Gitea bei fehlender Berechtigung auf ein privates Repository gibt — der Token existiert, er darf nur nicht. ## Die Asymmetrie ist das Problem | Modus | Checkout nutzt | Ergebnis bei `bk-dev-website` | | --- | --- | --- | | `push: 'false'` | Job-Token (Rückfall) | funktioniert | | `push: 'true'` | `jlab-git-checkout-token` aus 1Password | **scheitert** | Ob der Checkout funktioniert, hängt damit daran, ob gepusht wird. Das ist kein naheliegender Zusammenhang, und er kostet Zeit beim Suchen: Der Fehler sieht nach einem Rechteproblem am Repository aus, ist aber eines am geteilten Token. ## Lösungsrichtungen **1. Den Token berechtigen** — `jlab-git-checkout-token` Zugriff auf das aufrufende Repository geben. Schnell, aber es skaliert schlecht: Jedes neue Projekt braucht die Freigabe, und der Token sammelt mit der Zeit Rechte auf alles. **2. Den Checkout-Token opt-in machen** (empfohlen). Der Normalfall ist ein Repository ohne private Submodule; dort genügt der Job-Token. Eine Eingabe wie `private-submodules: 'false'` (Vorgabe) würde steuern, ob der Token überhaupt geholt und verwendet wird. Projekte mit privaten Submodulen setzen sie ausdrücklich. Damit verschwindet zugleich die im Ursprungstext beschriebene Einschränkung: Der Prüfmodus wäre dann nicht mehr schlechter gestellt als der Push-Modus, weil beide denselben Weg nehmen. **3. Den 1Password-Schritt zweiteilen** — Checkout-Token immer holen, Registry-Zugang nur beim Push. Behebt die Asymmetrie, lässt aber Lösungsrichtung 1 als Voraussetzung bestehen. ## Empfehlung Lösungsrichtung 2. Sie macht den Baustein für beliebige Repositories nutzbar, ohne dass ein geteilter Token überall Zugriff braucht — und sie folgt dem Grundsatz, dass der Sonderfall die Ausnahme sein sollte, nicht die Vorgabe.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: workflow-util/pipelines#3