Actions-Runner einrichten, isoliert vom Host #1

New issue

Open

opened 2026-09-23 17:02:52 +02:00 by arndttouby · 0 comments

arndttouby commented

2026-09-23 17:02:52 +02:00

Owner

Die Instanz hat keinen Actions-Runner (Administration → Actions → Runners: Total 0, erhoben 2026-09-23). Prüfungen laufen deshalb nur, wenn jemand daran denkt — vor dem Merge prüft nichts.

Anlass

tool-broker-config: Ein fehlerhaftes Regelwerk soll gar nicht erst gemergt werden. Der Prüfmodus tool-broker check entsteht in arndttouby/tool-broker#21 und läuft bis dahin auf dem Host vor dem Neustart.
tool-broker: cargo test und clippy vor dem Merge.
Weitere Repos (Skills, Cockpit-Meta-Repos) nach Bedarf, je eigener Schritt.

Der Kern: Der Runner führt Code des Agenten aus

Bei einem PR aus demselben Repo nimmt Forgejo den Workflow aus dem Head-Branch. Wer einen Branch pushen darf, bestimmt also, was auf dem Runner läuft — auch der Agent. Der tool-broker hält die Zugangsdaten vom Agenten fern; der Runner darf dafür keinen Seitenweg öffnen. Daraus folgen die Anforderungen:

Kein Docker-Socket des Hosts. Er wäre Root auf dem Forgejo-Server und damit Zugriff auf Datenbank, Repos und Tokens.
Jobs in Wegwerf-Containern ohne Mount auf Host-Pfade und ohne Zugang zu forgejo-db.
Keine Secrets für Workflows, solange kein Workflow sie braucht. Kommt einer hinzu, entscheidet das ein eigener Schritt.
Registrierung auf Repo- oder Nutzerebene, nicht global, und über Labels auf die vorgesehenen Repos begrenzt.
Image gepinnt nach container-supply-chain (Digest, Herkunft, Cooldown).

Vor der Umsetzung

Preflight mit zwei Gutachten aus verschiedenen Capability-Stufen (Betrieb, Sicherheit). Zu klären:

Wo läuft der Runner: als Kamal-Accessory auf dem Forgejo-Host oder auf einem eigenen Host? Der eigene Host trennt die Fehlerfolgen, kostet aber Betrieb.
Wie isoliert er die Jobs ohne Host-Socket: Docker-in-Docker, rootless Podman oder ein anderer Weg, den forgejo-runner unterstützt?
Welche Forgejo-Einstellungen müssen gesetzt sein ([actions], Standard-Actions-URL), und wohin zeigt uses: — auf eine Quelle außerhalb der Instanz oder auf einen Spiegel?
Wie kommt der Registrierungs-Token auf den Runner, ohne dass er im Cockpit liegt?

Nicht Teil dieses Vorgangs

Die Workflows der einzelnen Repos. Sie entstehen in den jeweiligen Vorgängen, zuerst in arndttouby/tool-broker#21.

Abschlusskriterium: Ein Runner ist registriert und in der Administration sichtbar; ein Workflow in tool-broker-config läuft auf einem PR und meldet seinen Status an den PR; ein Job erreicht weder den Docker-Socket noch Host-Pfade noch forgejo-db — belegt durch je einen fehlschlagenden Versuch; das Runner-Image ist per Digest gepinnt; die Einrichtung steht im README dieses Repos.

Die Instanz hat keinen Actions-Runner (Administration → Actions → Runners: Total 0, erhoben 2026-09-23). Prüfungen laufen deshalb nur, wenn jemand daran denkt — vor dem Merge prüft nichts. ## Anlass - **tool-broker-config:** Ein fehlerhaftes Regelwerk soll gar nicht erst gemergt werden. Der Prüfmodus `tool-broker check` entsteht in arndttouby/tool-broker#21 und läuft bis dahin auf dem Host vor dem Neustart. - **tool-broker:** `cargo test` und `clippy` vor dem Merge. - Weitere Repos (Skills, Cockpit-Meta-Repos) nach Bedarf, je eigener Schritt. ## Der Kern: Der Runner führt Code des Agenten aus Bei einem PR aus demselben Repo nimmt Forgejo den Workflow aus dem Head-Branch. Wer einen Branch pushen darf, bestimmt also, was auf dem Runner läuft — auch der Agent. Der tool-broker hält die Zugangsdaten vom Agenten fern; der Runner darf dafür keinen Seitenweg öffnen. Daraus folgen die Anforderungen: - **Kein Docker-Socket des Hosts.** Er wäre Root auf dem Forgejo-Server und damit Zugriff auf Datenbank, Repos und Tokens. - **Jobs in Wegwerf-Containern** ohne Mount auf Host-Pfade und ohne Zugang zu `forgejo-db`. - **Keine Secrets für Workflows**, solange kein Workflow sie braucht. Kommt einer hinzu, entscheidet das ein eigener Schritt. - **Registrierung auf Repo- oder Nutzerebene**, nicht global, und über Labels auf die vorgesehenen Repos begrenzt. - **Image gepinnt** nach `container-supply-chain` (Digest, Herkunft, Cooldown). ## Vor der Umsetzung Preflight mit zwei Gutachten aus verschiedenen Capability-Stufen (Betrieb, Sicherheit). Zu klären: - Wo läuft der Runner: als Kamal-Accessory auf dem Forgejo-Host oder auf einem eigenen Host? Der eigene Host trennt die Fehlerfolgen, kostet aber Betrieb. - Wie isoliert er die Jobs ohne Host-Socket: Docker-in-Docker, rootless Podman oder ein anderer Weg, den `forgejo-runner` unterstützt? - Welche Forgejo-Einstellungen müssen gesetzt sein (`[actions]`, Standard-Actions-URL), und wohin zeigt `uses:` — auf eine Quelle außerhalb der Instanz oder auf einen Spiegel? - Wie kommt der Registrierungs-Token auf den Runner, ohne dass er im Cockpit liegt? ## Nicht Teil dieses Vorgangs Die Workflows der einzelnen Repos. Sie entstehen in den jeweiligen Vorgängen, zuerst in arndttouby/tool-broker#21. **Abschlusskriterium:** Ein Runner ist registriert und in der Administration sichtbar; ein Workflow in tool-broker-config läuft auf einem PR und meldet seinen Status an den PR; ein Job erreicht weder den Docker-Socket noch Host-Pfade noch `forgejo-db` — belegt durch je einen fehlschlagenden Versuch; das Runner-Image ist per Digest gepinnt; die Einrichtung steht im README dieses Repos.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

arndttouby/forgejo-kamal#1

No description provided.

Rows
Columns