Gitea Actions : mettre en place un pipeline CI/CD auto-hébergé

Automatiser les tests, le build et le déploiement de vos projets sans dépendre de GitHub ou GitLab.

Quand on auto-héberge sa forge logicielle avec Gitea, la question du CI/CD finit toujours par se poser. Pendant longtemps, il fallait greffer un outil tiers — Drone, Jenkins, Woodpecker — avec sa propre configuration et ses propres contraintes. Depuis Gitea 1.19, Gitea Actions intègre nativement un moteur de CI/CD compatible avec la syntaxe GitHub Actions. C’est un changement de paradigme pour les équipes qui veulent une chaîne DevOps complète, souveraine et auto-hébergée.

Pourquoi Gitea Actions plutôt qu’un CI externe ?

Gitea Actions présente plusieurs avantages par rapport à un outil CI séparé :

Critère	CI externe (Jenkins, Drone)	Gitea Actions
Configuration	Fichier séparé, syntaxe spécifique	Fichier `.gitea/workflows/`, syntaxe YAML compatible GitHub Actions
Intégration UI	Interface séparée, double navigation	Résultats directement dans l’interface Gitea, sur chaque commit et PR
Maintenance	Service supplémentaire à mettre à jour	Intégré à Gitea, même cycle de mise à jour
Réutilisabilité	Écosystème propre, plugins spécifiques	Compatible avec de nombreuses GitHub Actions existantes
Runners	Agents propriétaires	`act_runner`, léger, déployable en Docker

Le point clé est la compatibilité avec la syntaxe GitHub Actions. Si votre équipe connaît déjà ce format, la migration vers Gitea Actions est quasi transparente. Les workflows existants fonctionnent souvent avec des ajustements minimes.

Architecture : Gitea + act_runner

Gitea Actions repose sur deux composants. Le serveur Gitea gère les workflows, les déclencheurs (push, pull request, cron) et l’affichage des résultats. L’exécution effective des jobs est déléguée à un ou plusieurs runners via le binaire act_runner. Ce runner peut tourner sur la même machine que Gitea ou sur des serveurs dédiés, et supporte trois modes d’isolation :

Docker (recommandé) : chaque job tourne dans un conteneur éphémère. Isolation complète, nettoyage automatique.
LXC : alternative plus légère aux conteneurs Docker, intéressante sur des serveurs à ressources limitées.
Host : exécution directe sur la machine du runner. À réserver aux cas où Docker n’est pas disponible.

Déploiement Docker Compose

Voici un docker-compose.yml complet qui déploie Gitea et un runner :

version: "3.9"
services:
  gitea:
    image: gitea/gitea:1.22
    ports:
      - "3000:3000"
      - "2222:22"
    volumes:
      - gitea-data:/data
    environment:
      GITEA__actions__ENABLED: "true"

  runner:
    image: gitea/act_runner:latest
    depends_on:
      - gitea
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - runner-data:/data
    environment:
      GITEA_INSTANCE_URL: http://gitea:3000
      GITEA_RUNNER_REGISTRATION_TOKEN: "${RUNNER_TOKEN}"

volumes:
  gitea-data:
  runner-data:

Le token d’enregistrement se récupère dans l’interface Gitea, sous Administration du site > Runners. Une fois le runner démarré, il apparaît dans la liste des runners disponibles et commence à traiter les jobs.

Sécurité du socket Docker : Le montage de /var/run/docker.sock donne au runner un accès complet au daemon Docker. En production, préférez un socket rootless ou utilisez un runner dédié sur une machine isolée.

Exemple de workflow : tester et déployer une application Python

Créez le fichier .gitea/workflows/ci.yaml à la racine de votre dépôt :

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Installer Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Installer les dépendances
        run: |
          pip install -r requirements.txt
          pip install pytest ruff

      - name: Vérifier le formatage (ruff)
        run: ruff check .

      - name: Lancer les tests
        run: pytest --tb=short -q

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Déployer via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          script: |
            cd /opt/mon-app
            git pull origin main
            docker compose up -d --build

Ce workflow exécute deux jobs. Le premier (test) vérifie le formatage du code avec ruff et lance les tests unitaires. Le second (deploy) ne s’exécute que sur la branche main, après le succès des tests, et déploie l’application via SSH sur le serveur de production.

Gérer les secrets

Gitea Actions supporte les secrets au même niveau que GitHub : par dépôt, par organisation, ou globalement. Les secrets sont chiffrés côté serveur et injectés comme variables d’environnement dans les jobs. On les définit dans Paramètres du dépôt > Actions > Secrets.

Pour un pipeline de déploiement, les secrets typiques sont : la clé SSH de déploiement, l’hôte cible, les credentials de registre Docker (si on pousse des images), et les tokens d’API pour les notifications (Mattermost, Matrix).

Cas d’usage concrets pour un SI open source

Pipeline CKAN

Tester automatiquement les extensions CKAN à chaque push : lancer les tests pytest dans un conteneur avec CKAN et PostgreSQL, vérifier la compatibilité avec les versions 2.10 et 2.11 via une matrice de builds, et déployer sur l’instance de staging en cas de succès sur la branche develop.

Pipeline Drupal

Valider les mises à jour de modules : exécuter phpcs pour le respect des standards de codage, lancer les tests PHPUnit, puis déclencher un drush deploy sur le serveur de recette.

Pipeline infrastructure

Valider les fichiers de configuration avant déploiement : linter les fichiers Docker Compose avec docker compose config, vérifier la syntaxe Nginx avec nginx -t dans un conteneur, puis appliquer les changements via Ansible si le linting passe.

Optimisations et bonnes pratiques

Cache des dépendances : utilisez l’action actions/cache pour éviter de retélécharger pip, npm ou composer à chaque build. Le gain de temps est significatif sur les projets avec beaucoup de dépendances.
Matrice de tests : testez sur plusieurs versions de Python, Node ou PHP en parallèle avec la directive strategy.matrix.
Workflows réutilisables : factorisez les étapes communes dans des workflows appelables (workflow_call) stockés dans un dépôt central.
Timeouts : définissez un timeout-minutes sur chaque job pour éviter qu’un test bloqué ne monopolise le runner indéfiniment.
Nettoyage des artefacts : configurez une rétention courte (7 jours) pour les logs et artefacts de build afin de ne pas saturer le stockage Gitea.

Limites actuelles

Gitea Actions est encore un projet relativement jeune. Quelques points à garder en tête :

Toutes les GitHub Actions tierces ne sont pas compatibles — celles qui appellent des API spécifiques à GitHub (comme les actions de release) nécessitent des adaptations.
L’écosystème de runners est plus restreint : pas d’équivalent aux runners macOS/Windows hébergés de GitHub.
La documentation officielle progresse rapidement mais reste moins fournie que celle de GitHub Actions.
Les composite actions et les reusable workflows sont supportés, mais certaines fonctionnalités avancées (comme les environments avec approbation) sont encore en développement.

Récapitulatif

Gitea Actions transforme Gitea d’une simple forge Git en une plateforme DevOps complète et auto-hébergée. La compatibilité avec la syntaxe GitHub Actions réduit la courbe d’apprentissage et permet de réutiliser une partie de l’écosystème existant. Pour les équipes qui gèrent un SI open source — CKAN, Drupal, scripts d’infrastructure — c’est le moyen le plus direct d’intégrer du CI/CD sans ajouter de brique logicielle supplémentaire ni dépendre d’un service cloud tiers.

GiteaCI/CDDevOpsDockerauto-hébergementopen sourceact_runnerpipelinedéploiement