Gitea a publié la version 28.0.0 le 30 septembre, abandonnant au passage le préfixe « 1. » que le projet traînait depuis sa toute première version stable. La dernière mouture de l’ancienne série était la 1.27.x ; la suivante n’est plus 1.28.0, mais tout simplement 28.0.0. Sur le papier, le changement semble anecdotique. Mais il en dit long sur la façon dont le projet se perçoit désormais : moins un éternel chantier 1.x, plus un outil mature avec sa propre ligne de versions.
Les notes de version, publiées sur le blog officiel de Gitea, sont copieuses. Voici ce qui compte vraiment si vous gérez votre propre instance.
Administration et sécurité
La nouveauté phare, c’est la journalisation d’audit. Gitea enregistre désormais les actions sensibles effectuées dans les réglages d’administration, les organisations, les dépôts et les comptes utilisateurs, ce qui permet aux responsables d’instance de savoir qui a fait quoi, et quand. Les forges Git auto-hébergées accusaient un vrai retard sur GitLab et GitHub sur ce terrain depuis des années ; cette version comble enfin le manque.
28.0.0 introduit aussi des comptes bots dédiés, qui s’authentifient uniquement par jeton d’accès, jamais par mot de passe. C’est une configuration bien plus propre pour les pipelines CI et les scripts d’automatisation que de réutiliser le compte d’un humain. Les administrateurs héritent par ailleurs d’une fonction d’impersonation : ils peuvent visualiser l’instance comme le ferait un utilisateur donné, ce qui évite de demander un partage d’écran rien que pour reproduire un bug de permissions.
Autre changement plus discret mais franchement pratique : la configuration Redis est désormais partagée entre les sous-systèmes, au lieu d’exiger des réglages distincts pour le cache, les sessions et les files d’attente. Quiconque fait tourner Redis derrière Gitea y gagne un fichier de configuration plus court.
Fonctionnalités de collaboration
Les jetons de déploiement HTTPS, limités à un dépôt donné, font leur apparition dans cette version, en équivalent HTTPS des clés de déploiement SSH. Si vous êtes resté sur des clones HTTPS pour éviter de gérer des clés SSH, vous disposez maintenant d’une option de jeton restreint plutôt que de distribuer des identifiants de compte complets.
Les revues de pull requests gagnent une recherche dans les diffs et un filtrage par extension de fichier, deux ajouts utiles sur les grosses PR où défiler fichier par fichier fait perdre du temps. La protection de branche peut désormais exiger spécifiquement l’approbation d’un code owner, et non plus celle de n’importe quel contributeur disposant des droits d’écriture. S’ajoutent aussi un sélecteur de dépôt dans l’en-tête pour naviguer entre les dépôts d’un même propriétaire, des réglages de notification plus fins par dépôt, et une détection de licence façon REUSE qui gère correctement les dépôts multi-licenciés au lieu de supposer qu’une seule licence couvre tout.
Actions et CI/CD
Gitea Actions gagne une vraie visibilité sur la file d’attente : on voit enfin quels jobs tournent ou patientent, au lieu de deviner devant un écran vide. Les aperçus d’artefacts affichent désormais directement dans le navigateur les fichiers texte, les images, les PDF et les rapports HTML. Les matrices de build s’évaluent dynamiquement, on peut plafonner le nombre de jobs exécutés en parallèle, et la liste des exécutions de workflow se rafraîchit toute seule, sans rechargement manuel.
Changements majeurs à anticiper
Plusieurs changements de 28.0.0 cassent les configurations existantes si vous sautez les mises à jour de config correspondantes :
- Les opérations réseau Git comme les migrations et le mirroring passent désormais par un proxy interne avec de nouvelles règles de sortie. Il faut définir
EGRESS_MODEpour que cela continue de fonctionner. - Les exécutions Actions terminées expirent au bout de 400 jours par défaut. Réglez
RUN_RETENTION_DAYS = 0pour les conserver indéfiniment. - Git 2.25.0 ou plus récent est désormais requis côté serveur.
- L’auto-inscription est désactivée par défaut. Si votre instance repose sur des inscriptions ouvertes, il faut explicitement fixer
DISABLE_REGISTRATION = false. - L’évaluation des conditions de workflow et de matrice est plus stricte, ce qui peut changer le comportement de workflows Actions existants.
Qu’en est-il des correctifs de sécurité ?
L’équipe Gitea est restée discrète sur la plupart des détails de sécurité de cette version, mais a confirmé quelques correctifs : les objets Git invalides sont désormais rejetés d’office, l’identification des empreintes de clés SSH a été améliorée, et les pull requests venant de forks sont désormais verrouillées en attente d’approbation, ce qui ferme une voie d’abus connue.
Gitea et Forgejo, toujours à se tourner autour
Gitea et son fork Forgejo se tiennent à distance prudente l’un de l’autre depuis la scission de 2022, et l’année leur a offert à chacun sa propre frayeur sécurité. Gitea avait corrigé deux vulnérabilités critiques en janvier avec la 1.27.1. Forgejo, de son côté, a corrigé en septembre un RCE critique dans les modèles de dépôt, référencé CVE-2026-89094, dans ses versions 16.0.4 et 15.0.8. Aucun des deux incidents ne devrait vraiment peser dans le choix de l’un ou l’autre aujourd’hui : la 28.0.0 se suffit à elle-même comme version majeure, et le journal d’audit à lui seul est une fonctionnalité que les self-hosters réclamaient depuis longtemps.
Faut-il mettre à jour ?
Si vous faites tourner Gitea, lisez la section des changements majeurs avant de toucher au bouton de mise à jour, en particulier les réglages par défaut du mode de sortie réseau et de l’auto-inscription. Ce sont précisément le genre de paramètres qui bloquent silencieusement un job de mirroring ou un parcours d’inscription attendu si on ne les repère pas à temps. Le détail complet se trouve sur le billet officiel de sortie de Gitea 28.0.0. Pour voir comment Gitea se positionne face à Forgejo et GitLab côté self-hosting, direction nos fiches Gitea et Forgejo.