Continue integratie — Gitea Acties

Machinevertaling van het Franse origineel.

De omgeving voert zijn workflows uit met act_runner, op vm-compute-01, in de modus dind: de taken draaien in de Docker-daemon van de runner, niet in die van de host.

Het pad van een push

flowchart LR
    dev["Poste<br/>git push"]
    gitea["Gitea<br/>vm-docker:3303"]
    runner["act_runner<br/>vm-compute-01"]
    job["Job dans<br/>node:20-bookworm"]
    hote["vm-docker<br/>deploy-hook.sh"]

    dev --> gitea
    gitea -.->|"le runner interroge,<br/>Gitea ne pousse pas"| runner
    runner --> job
    job -->|"ssh, clé verrouillée<br/>par command="| hote
    hote --> ok["git pull + build<br/>+ vérification"]

De runner haalt de taak op via een lange query: Gitea doet dit nooit. Daarom staat er in de configuratie een directe IP-URL — via Caddy lijkt deze continue query op een scan en zou het door CrowdSec geblokkeerd kunnen worden.

De duurste val: de reikwijdte van een runner

Een act_runner heeft een unieke reikwijdte, gekoppeld aan een registratie — instance, organisatie, gebruiker, of een enkele repository. Deze verandert niet later.

flowchart TB
    subgraph hote["vm-compute-01"]
        r1["rtx-runner<br/>portée : dépôt homelab-vault"]
        r2["docs-runner<br/>portée : dépôt homelab-docs"]
    end

    v["Dépôt homelab-vault"]
    d["Dépôt homelab-docs"]
    t["Un troisième dépôt"]

    r1 --> v
    r2 --> d
    t -.->|"aucun runner éligible"| queued["runs « queued »<br/>indéfiniment"]

    classDef bad stroke-width:3px,stroke-dasharray: 5 5
    class queued bad

Permanente runs queued lijken geen fout

Als er geen runner beschikbaar is, verschijnen de uitvoeringen normaal in de interface en blijven ze queued. Er zijn geen berichten, geen waarschuwingen, niets dat aangeeft dat er niemand ze zal ophalen. Dit wordt geïnterpreteerd als "de CI is nog niet verbonden".

De controle die resulteert in een enkele query:

curl -s -H "Authorization: token $TOKEN" \
  https://gitea.savethemall.eu/api/v1/repos/<owner>/<repo>/actions/runners \
  | jq '.runners[].name'
# tableau vide → ces jobs ne partiront jamais

Het toevoegen van een repository aan de CI, betekent dus ofwel het toevoegen van een runner, of het migreren van een bestaande runner naar een grotere reikwijdte — deze tweede optie stopt de CI, die hij voorheen gebruikte, met een "koude" start.

Het registratie-token wordt aangevraagd via POST, niet via GET:

POST /api/v1/repos/<owner>/<repo>/actions/runners/registration-token

Wat de taak-image bevat — en niet bevat

De taken runs-on: ubuntu-latest worden uitgevoerd in node:20-bookworm.

Aanwezig	Afwezig
git 2.39	pip
Python 3.11	venv
Toegang tot github.com en pypi.org	SSH-client

Debian levert pip, venv en openssh-client apart. Een workflow die deze verwacht, faalt later, na het ophalen, met een bericht dat niet aangeeft dat er een pakket ontbreekt.

actions/setup-python werkt niet op deze runner

::error::The version '3.12' with architecture 'x64' was not found
for this operating system.

De actie downloadt binaire bestanden die beschikbaar zijn voor de afbeeldingen ubuntu-XX van GitHub. Er zijn er nog niet voor Debian bookworm. Dit is geen probleem met het netwerk: de runner kan zonder problemen verbinding maken met github.com en pypi.org.

Installeren vanuit Debian in plaats daarvan:

- name: Installer Python et les dépendances
  run: |
    apt-get update -qq
    apt-get install -y --no-install-recommends python3-venv python3-pip
    python3 -m venv /tmp/venv
    /tmp/venv/bin/pip install --no-cache-dir -r requirements.txt

Implementeren zonder een shell{ #deployer-sans-donner-un-shell }

Een implementatiesleutel die een volledige shell op de productieomgeving opent, is even waardevol als het wachtwoord van die omgeving. De hier gebruikte methode reduceert dit tot één enkele actie:

command="/opt/docker/<stack>/deploy-hook.sh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty,restrict ssh-ed25519 AAAA…

Wat de client ook stuurt, de server voert dit script uit en niets anders. De controle, in plaats van aan te nemen:

ssh -i <clé> -p <port-ssh> <user>@vm-docker "cat /etc/shadow"
# doit afficher la sortie du déploiement, jamais le contenu du fichier

Een ontwerpvolgorde: het script moet zelf de controle uitvoeren, aangezien de client geen tweede opdracht kan sturen om het resultaat te controleren.

Dernière vérification de cette page : 2026-09-08