Gitea 28.0 - audit et CI/CD pour votre forge Git auto-hébergée

Gitea 28.0.0 est disponible depuis le 30 septembre 2026. Le projet abandonne le préfixe 1. dans sa numérotation et enrichit sa forge Git auto-hébergée. Annonce officielle Gitea.

Pour une entreprise, une forge ne contient pas seulement du code. Elle porte aussi les échanges techniques, les règles de validation et une partie de la chaîne de livraison. En reprendre la maîtrise permet de décider où ces éléments résident et comment ils restent disponibles.

Cette version mérite donc une lecture d’exploitation : mieux attribuer les actions, encadrer les automatisations et comprendre ce qui se passe entre un changement de code et sa livraison.

Une forge Git auto-hébergée pour garder la maîtrise de son code

Choisir l’auto-hébergement répond à des besoins concrets : conserver les dépôts dans un environnement choisi, organiser les accès des collaborateurs et des prestataires, ou rapprocher les outils de développement de l’infrastructure applicative.

Cela permet aussi de traiter la disponibilité de la forge comme un sujet d’architecture. Si l’équipe doit pouvoir préparer un correctif pendant un incident chez un fournisseur, il faut anticiper ses dépendances avant la panne. Nous abordons cette question dans notre analyse de la continuité du développement avec une forge maîtrisée.

Le bénéfice n’est pas de supprimer toute dépendance. C’est de pouvoir choisir celles qui restent acceptables, documenter les autres et préparer une reprise adaptée au métier.

Gitea 28.0 facilite les accès techniques et le suivi des pipelines

La nouvelle version introduit des comptes dédiés aux automatisations et des jetons HTTPS limités à un dépôt. Elle ajoute l’approbation obligatoire des responsables définis dans CODEOWNERS, ainsi qu’une vue des tâches Actions en cours et en attente. Fonctionnalités de Gitea 28.0.

Ces évolutions répondent à des situations courantes. Un script qui récupère un dépôt n’a pas besoin de dépendre du compte personnel d’un développeur. Une modification sensible doit pouvoir être relue par l’équipe responsable. Et un pipeline bloqué doit être identifiable sans parcourir chaque projet.

Gitea Actions fournit le mécanisme d’intégration et de livraison continues. Les tâches sont exécutées par des runners, les agents chargés de construire le logiciel, lancer les tests ou réaliser les opérations prévues dans un workflow. La documentation rappelle que la compatibilité avec GitHub Actions comporte des différences. Présentation officielle de Gitea Actions.

Notre recommandation est de séparer les droits de lecture, de construction et de déploiement. Un test lancé sur une contribution ne devrait pas disposer par défaut des mêmes secrets qu’une livraison en production. Cette séparation doit se retrouver dans les comptes, les machines d’exécution et les accès réseau.

C’est le même enjeu que dans une chaîne CI/CD intégrée à un cloud privé : l’automatisation devient utile lorsqu’elle s’inscrit dans une infrastructure dont les responsabilités sont claires.

Les journaux d’audit donnent du contexte aux changements

Gitea dispose désormais d’un journal d’audit structuré, distinct des journaux techniques. Il permet de retrouver des changements sensibles et de les filtrer par acteur, action ou origine. L’enregistrement est désactivé par défaut ; sa conservation initiale est de 30 jours. Documentation de l’audit Gitea.

Pour l’activer, la documentation prévoit cette configuration dans app.ini, suivie d’un redémarrage :

[audit]
RECORD_OUTPUT = database
RETENTION_DAYS = 30

Ce réglage est un point de départ, pas une politique de conservation universelle. Nous recommandons de définir les événements utiles, les personnes autorisées à les consulter et la durée nécessaire aux investigations.

Le journal ne couvre notamment pas les consultations, les clones et les requêtes API en lecture seule. Il doit donc être complété par les journaux d’accès et la supervision du service. Périmètre des événements enregistrés.

L’intérêt opérationnel est simple : après un changement inattendu de droits ou de configuration, l’équipe dispose d’éléments pour reconstituer la situation. Encore faut-il vérifier que les traces sont effectivement produites et conservées.

Préparer la mise à niveau de Gitea sans surprise

La version change aussi certains comportements : règles de connexions sortantes, notifications désormais transportées par WebSocket et suppression par défaut des exécutions Actions terminées depuis plus de 400 jours. Git 2.25 minimum est requis. Des correctifs de sécurité sont inclus, avec des détails annoncés ultérieurement. Changements incompatibles et sécurité.

Nous retiendrions quatre contrôles avant la bascule :

1. Inventorier les dépendances. Authentification, reverse proxy, miroirs, webhooks, runners et stockages doivent figurer dans le périmètre de recette.
2. Décider de la conservation. Vérifier quels historiques, journaux et artefacts doivent rester accessibles, puis adapter les réglages avant la mise à niveau.
3. Tester les usages réels. Un démarrage réussi ne valide pas un clone SSH, une récupération HTTPS, une revue de code ou un pipeline de livraison.
4. Préparer la reprise. Conserver une sauvegarde cohérente et une procédure de restauration testée avant de modifier l’instance de production.

Pour les connexions sortantes, il faut en particulier relire les listes d’autorisation : en mode lax, ALLOWED_HOST_LIST ne restreint plus les hôtes publics. Le mode strict permet de maintenir une liste exclusive. Règles réseau de la nouvelle version.

Sauvegarder la forge, pas seulement les dépôts Git

Un clone conserve du code, mais il ne reconstitue pas toute la plateforme. Gitea repose sur une base de données, des fichiers et des dépôts qui évoluent ensemble. Sa documentation de sauvegarde demande l’arrêt de l’instance pour garantir leur cohérence et décrit la restauration comme une procédure manuelle. Sauvegarde et restauration Gitea.

Nous recommandons de tester la reprise sur un environnement isolé : connexion d’un utilisateur, présence des projets, accès aux fichiers utiles et exécution d’un workflow représentatif. Les stockages externes éventuels doivent être intégrés au plan, pas supposés couverts par la sauvegarde du serveur.

La disponibilité doit également être pensée pendant un incident : où sont les procédures si la forge est indisponible ? Comment retrouver les configurations et les accès nécessaires pour la restaurer ? Ces questions sont plus utiles qu’une sauvegarde déclarée réussie mais jamais éprouvée.

Une autonomie qui se construit dans l’exploitation

Gitea 28.0 apporte des outils utiles aux équipes qui veulent héberger leur forge. Leur valeur se mesure dans le quotidien : des accès mieux délimités, des changements compréhensibles et une chaîne de livraison que l’on sait remettre en service.

Chez Forget About IT, notre approche de l’infogérance de serveurs Linux relie précisément ces sujets : maintenance, supervision, sauvegardes et procédures d’intervention. L’objectif est que votre équipe puisse travailler sur son produit avec une infrastructure suivie dans la durée.

Vous envisagez de reprendre la maîtrise de votre forge ou de fiabiliser son exploitation ? Échangeons sur votre infrastructure et ses dépendances.

FAQ - Gitea et auto-hébergement

Pourquoi héberger sa forge Git avec Gitea ?

L’auto-hébergement permet de choisir où résident le code et les données de collaboration, comment les accès sont gérés et comment le service est sauvegardé. Il suppose d’organiser la maintenance, la supervision et la restauration.

Les journaux d’audit Gitea sont-ils activés automatiquement ?

Non. Leur enregistrement doit être activé dans la configuration. La conservation par défaut est de 30 jours. Ils ne remplacent pas les journaux d’accès et ne couvrent pas toutes les opérations de lecture.

Un clone Git suffit-il pour sauvegarder Gitea ?

Non. La restauration de la forge nécessite aussi ses données applicatives, sa configuration et les fichiers associés. La sauvegarde doit être cohérente et son périmètre vérifié, notamment lorsque des stockages externes sont utilisés.