Integrazione continua — Gitea Actions

Traduzione automatica dell'originale francese.

Il parco esegue i suoi flussi di lavoro con act_runner, su vm-compute-01, in modalità dind: i lavori vengono eseguiti nel demone Docker del runner, non in quello dell'host.

Il percorso di un 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"]

Il runner accede al lavoro tramite interrogazione: Gitea non lo contatta mai. Di conseguenza, l'URL con indirizzo IP diretto nella sua configurazione — tramite Caddy, questa interrogazione permanente assomiglia a una scansione e verrebbe bloccata da CrowdSec.

La trappola più costosa: l'ambito di un runner

Un act_runner ha un ambito unico, fissato all'istanza — utente, organizzazione, o un singolo repository. Non cambia dopo.

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

Eseguire queued in modo permanente non è un errore

Quando non è disponibile alcun runner, le esecuzioni appaiono normalmente nell'interfaccia e rimangono queued. Non ci sono messaggi, né avvisi, né nulla che indichi che nessuno le prenderà. Sembra come se "il CI non fosse ancora attivo".

Il controllo che si basa su una singola richiesta:

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

Aggiungere un repository al CI significa quindi aggiungere un runner, oppure migrare un runner esistente a un ambito più ampio — in questo caso, la CI smette di funzionare durante l'operazione, richiedendo un riavvio.

Il token dell'istanza viene richiesto tramite POST, non GET:

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

Cosa contiene l'immagine dei lavori — e cosa non contiene

I lavori runs-on: ubuntu-latest vengono eseguiti in node:20-bookworm.

Presente	Assente
git 2.39	pip
Python 3.11	venv
accesso a github.com e pypi.org	client SSH

Debian fornisce pip, venv e openssh-client separatamente. Un flusso di lavoro che li presuppone fallisce tardi, dopo il checkout, con un messaggio che non indica la mancanza di un pacchetto.

actions/setup-python non funziona su questo runner

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

L'azione scarica i binari pubblicati per le immagini ubuntu-XX di GitHub. Non esistono per Debian bookworm. Non si tratta di un problema di rete: il runner riesce ad accedere a github.com e pypi.org senza difficoltà.

Installare invece da Debian:

- 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

Deploy senza shell

Una chiave di deploy che apre un shell completo sull'host di produzione vale la password di questo host. La forma utilizzata qui la riduce a un singolo gesto:

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

Qualunque comando invii, il server esegue questo script e solo questo. Invece di presumere, è meglio dimostrarlo:

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

Corollario di progettazione: lo script deve effettuare da solo la sua verifica, poiché il client non può inviare un secondo comando per controllare il risultato.

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