Gitea Actions, premier contact

30/03/2023 6 minutes de lecture

Dans notre monde actuel de Cloud et de DevOps, quelle fonctionnalité quasi-indispensable manque-t-il à Gitea, la forge Git open source ?
Un système de CI/CD, mais… plus pour très longtemps !

Faites place à Gitea Actions !

La première mention concrète de la fonctionnalité par un des développeurs principaux date de novembre 2020, et aujourd’hui elle pointe le bout de son nez dans les releases.
Pour faciliter son adoption, la configuration des pipelines se fait de la même façon que le CI/CD de GitHub. Actuellement une bonne partie des actions sont compatibles, mais plusieurs fonctionnalités ne sont pas encore terminées (au moment où j’écris ces lignes le dernier commit lié aux Gitea Actions date d’à peine 2 heures !).

Les développements vont bon train, et une première distribution expérimentale de celle-ci s’est faite dans la version 1.19 (dernière version en date lors de la publication de ce billet).

Jusqu’alors, le CI/CD pour Gitea se faisait uniquement par le biais de système tiers. Des options populaires incluaient Drone CI et son fork open source Woodpecker, Agola, Metroline ou encore ce bon vieux Jenkins (toujours vivant !).

Mais l’intégration était quasiment à sens unique. Les systèmes de CI suivaient, le plus souvent à l’aide d’un Webhook, ce qui se passe sur les repos Git, et lançaient au besoin un pipeline. Et si vous étiez chanceux, le résultat était hébergé dans un registry de Gitea (npm, Maven, PyPI, etc). Fin.

Actuellement, en plus du système Gitea Actions, Gitea va de l’avant pour renforcer ces intégrations et permettre à ces outils tiers d’afficher des informations sur les pipelines directement au sein de Gitea. Mais c’est une autre histoire. On est là pour les Gitea Actions aujourd’hui !

Activer les actions dans Gitea

Puisqu’encore expérimentale, la fonctionnalité est désactivée par défaut. Pour l’activer, rendez vous dans votre fichier de configuration conf/app.ini, et ajoutez, à la section [actions], la clé ENABLED avec une valeur true.

# app.ini
[actions]
ENABLED = true

Besoin d'aide pour localiser le fichier de configuration ?

Dans l’interface de Gitea, cliquez sur votre avatar en haut à droite puis

interface en anglais : page Site Administration > onglet Configuration > Configuration File Path
interface en français : page Administration du site > onglet Configuration > Chemin du fichier de configuration

Petit coup de redémarrage de Gitea (varie selon votre méthode d’installation), puis allez sur un projet et dans les paramètres, à l’onglet Dépôt/Repository, cochez la case correspondante pour activer les actions sur ce projet, et voilà !

Mise en place d’un runner sous Linux

Une fois la fonctionnalité activée, il faut maintenant installer, configurer puis faire tourner un runner : c’est un programme “exécuteur”, qui se connecte au serveur Gitea et attend une demande de pipeline pour réaliser le workflow de build. Le runner de Gitea s’appelle act_runner et est un fork de act, petit programme qui permet de lancer des actions GitHub en local.

Déployer le runner sous forme de connecteur Docker

À l’heure de la version 1.19, le runner n’est installable que sous forme d’exécutable binaire.
Une image Docker est cependant en développement.

Nous allons maintenant procéder à la mise en place d’un runner Gitea.

Choper le binaire

Au choix, vous pouvez cloner le repo d’act_runner puis lancer un make build, ou bien télécharger un exécutable pré-compilé. Dans tous les cas, vous devriez vous retrouver avec un exécutable binaire act_runner quelque part sur votre système.

Liaison avec l’instance Gitea

Il faut maintenant se lier (d’amitié) avec votre instance Gitea. Pour cela, exécutez la commande suivante

./act_runner register

2 informations supplémentaires vont vous être demandées : l’URL de votre instance Gitea, puis le token d’enregistrement de ce runner.
Le token se trouve sur la partie Administration du site > onglet Runners, en cliquant sur le bouton Create new Runner.
Vous pouvez ne rien répondre aux 2 questions suivantes pour garder les paramètres par défaut.

Un fichier .runner devrait avoir été créé dans le dossier courant.

Démarrage du runner

Un petit coup de

./act_runner daemon

et vous devriez voir sur l’onglet Runners que votre runner est en ligne !

Erreur « msg="cannot accept task" error="deadline_exceeded: Post... »

Si vous avez cette erreur, faites attention à ce que le nom de domaine de votre instance Gitea soit correctement résolu par votre DNS (la configuration réseau des serveurs auto-hébergés est parfois assez tarabiscotée… 😅).

C’est l’heure de systemd-iser notre runner !

Le souci avec le runner actuel est qu’on doit le lancer “à la main”.

Nous allons créer un service Systemd pour nous permettre de plus facilement gérer le programme.

# Création du fichier puis configuration des permissions
sudo touch /etc/systemd/system/gitea-act-runner.service
sudo chmod 644 /etc/systemd/system/gitea-act-runner.service

Ouvrez maintenant le fichier nouvellement créé avec votre éditeur préféré, et ajoutez y le code suivant en remplaçant les chemins par ceux corrects pour votre machine :

[Unit]
Description=Gitea act runner

[Service]
Environment="GITEA_RUNNER_FILE=/path/to/the/.runner"
ExecStart=/path/to/the/binary/act_runner daemon

[Install]
WantedBy=multi-user.target

Et la dernière étape :

# Dire à Systemd de charger les nouveaux services
sudo systemctl daemon-reload

# On démarre le service !
sudo systemctl start gitea-act-runner.service

Et voici le résultat de sudo systemctl status gitea-act-runner.service :

● gitea-act-runner.service - Gitea act runner
     Loaded: loaded (/etc/systemd/system/gitea-act-runner.service; disabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-03-28 01:39:35 CEST; 22s ago
   Main PID: 288035 (act_runner)
      Tasks: 8 (limit: 9296)
     Memory: 16.6M
        CPU: 72ms
     CGroup: /system.slice/gitea-act-runner.service
             └─288035 /usr/local/bin/act_runner daemon

Mar 28 01:39:35 debin systemd[1]: Started Gitea act runner.
Mar 28 01:39:35 debin act_runner[288035]: time="2023-03-28T01:39:35+02:00" level=info msg="Starting runner daemon"
Mar 28 01:39:35 debin act_runner[288035]: time="2023-03-28T01:39:35+02:00" level=info msg="successfully ping the docker daemon"
Mar 28 01:39:35 debin act_runner[288035]: time="2023-03-28T01:39:35+02:00" level=error msg="cannot init cache server, it will be disabled: $HOME is not defined"
Mar 28 01:39:35 debin act_runner[288035]: time="2023-03-28T01:39:35+02:00" level=info msg="polling the remote server" arch=amd64 capacity=1 endpoint="https://git.my.domain/" os=linux
Mar 28 01:39:35 debin act_runner[288035]: time="2023-03-28T01:39:35+02:00" level=info msg="poller: request stage from remote server" func=pollTask
Mar 28 01:39:40 debin act_runner[288035]: time="2023-03-28T01:39:40+02:00" level=info msg="poller: request stage from remote server" func=pollTask
Mar 28 01:39:45 debin act_runner[288035]: time="2023-03-28T01:39:45+02:00" level=info msg="poller: request stage from remote server" func=pollTask
Mar 28 01:39:50 debin act_runner[288035]: time="2023-03-28T01:39:50+02:00" level=info msg="poller: request stage from remote server" func=pollTask
Mar 28 01:39:55 debin act_runner[288035]: time="2023-03-28T01:39:55+02:00" level=info msg="poller: request stage from remote server" func=pollTask

Voilà, vous savez maintenant comment installer et configurer la première version de Gitea Actions. Il ne vous reste plus qu’à écrire vos workflows et buildez jeunesse !

PS : Petite anecdote méta, ce blog est publié de façon entièrement automatisée par le CI/CD de Gitea Actions !

Je ne sais toujours pas comment terminer mes articles.