Installation d'un runner Gitea
Dans mon bilan de fin d'année j'évoquais mon instance Gitea qui héberge mes projets privés et réplique mes projets publics. Depuis peu je lui ai greffé un petit moteur d'intégration continue : un act_runner, le runner officiel de Gitea Actions.
Pourquoi un runner CI pour un usage personnel ? J'ai quelques scripts et outils maison et je publie sur Gitea les images Docker de ces outils depuis ma machine de développement avec un simple Makefile. Avoir une petite CI permet de faire une publication plus officielle en se basant sur les tags de version Git.
Gitea s'exécute dans un container Docker d'une VM Debian de Proxmox. J'aurais pu installer le runner sur la même VM mais j'ai préféré ne pas pénaliser les autres services de la VM et installer le runner dans un container séparé... container et non pas machine virtuelle car je voulais du léger — les ressources du MiniPC ne sont pas inépuisables — donc j'ai opté pour le container LXC Docker via les Proxmox VE community scripts, le projet communautaire qui a pris la suite des fameux scripts de tteck.
Une seule commande à coller dans le shell Proxmox :
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/docker.sh)"
Le script pose quelques questions en mode interactif, crée le container LXC, installe Docker et configure les services. C'est bluffant de rapidité. J'ai alloué 2 cœurs et 2 Go de RAM — je peux ajuster plus tard en fonction des besoins réels, Proxmox rend ça trivial.
Toutefois, faire tourner Docker dans un container LXC n'est pas la configuration recommandée par Proxmox, qui préconise une VM dédiée pour ça. Le script rend cela possible en créant un container privilégié. Pour un runner CI perso derrière le pare-feu Proxmox, le compromis me convient.
Une fois le container démarré, on récupère le binaire de l'act_runner depuis les releases officielles de Gitea et on l'enregistre auprès de son instance.
Côté Gitea, il faut d'abord générer un token. Ça se passe dans l'interface d'administration : Administration du site → Actions → Exécuteurs. On copie le token proposé et on retourne dans le container.
L'enregistrement est interactif :
cd /srv/gitea-runner
./act_runner register
Le programme demande l'URL de l'instance, le token, un nom pour le runner et des labels. J'ai gardé les labels par défaut (ubuntu-latest, ubuntu-22.04, ubuntu-20.04) qui couvrent la majorité des workflows qu'on croise dans la nature. À la fin, un fichier .runner est généré dans le répertoire courant — il contient les credentials du runner.
On génère ensuite le fichier de configuration :
./act_runner generate-config > config.yaml
j'ai gardé le fichier généré tel quel.
Il ne reste plus qu'à écrire un service systemd qui démarre notre runner avec la commande :
/srv/gitea-runner/act_runner daemon
Le runner apparaît alors dans l'interface Gitea avec le statut Inactif.
Un petit test de workflow m'a permis de valider que tout fonctionne : le job s'affiche en vert dans l'onglet Actions du dépôt. Le runner a bien chopé le job, Docker a tiré l'image ubuntu-latest et le job a tourné dans son container éphémère. Ca implique évidemment que le container LXC a un accès sortant à internet pour tirer les actions et les images. La première exécution du job est un peu lente car les images Docker ne sont pas encore mises en cache localement.
Ca s'installe assez rapidement sans tatônnements, la documentation de Gitea est suffisante. Dans mon cas, le plus long a été de décider la cible de déploiement du runner et d'appliquer mes règles de pare-feu. Le runner dort sagement en attendant un push, il consomme peu, c'est exactement ce que je cherchais.