Sortie de Forgejo v16.0 — notifications, revues de PR et Actions enrichies

 (forgejo.org)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Forgejo v16.0, publié le 16 juillet 2026, étend les notifications par dépôt, le suivi de progression des migrations, les revues de pull requests, ainsi que les fonctionnalités Actions et API
  • La défense contre les SSRF a été renforcée en bloquant les redirections HTTP des miroirs Git ; les dépôts distants dont le nom ou le propriétaire a changé doivent voir leur URL de miroir mise à jour manuellement
  • Si vous utilisez l’authentification par proxy inverse dans un conteneur, vous devez indiquer les plages d’adresses de proxy de confiance ; certaines configurations existantes exposant le port web par défaut à un réseau non fiable ne fonctionneront plus
  • Ajout des revues multi-lignes, du suivi de position des commentaires basé sur git blame --reverse, de la priorité d’exécution des Actions, des Authorized Integrations basées sur JWT, ainsi que des API pour les journaux de workflows, les artefacts et l’annulation
  • v16.0 est une version non LTS, prise en charge jusqu’au 29 octobre 2026 ; avant la mise à niveau, il faut effectuer une sauvegarde complète et vérifier tous les changements de compatibilité

Sortie et mise à niveau

Changements de compatibilité et renforcement de la sécurité

  • Défense SSRF pour les miroirs Git

    • Correction d’un problème où [migrations].ALLOWED_DOMAINS, LOCKED_DOMAINS et ALLOW_LOCALNETWORKS n’étaient pas correctement appliqués dans certains cas d’exception
    • Application de http.followRedirects=false afin d’empêcher Git de contourner la configuration en suivant des redirections lors de l’accès à des dépôts HTTP(S)
    • Les dépôts Forgejo distants renommés ou transférés à un nouveau propriétaire verront leurs redirections traitées comme des erreurs ; les miroirs existants doivent donc être mis à jour avec la nouvelle adresse du dépôt

  • Suppression du retrait des EXIF des avatars

    • La fonction de suppression des métadonnées EXIF des images d’avatar, ajoutée en v13.0, a été supprimée en raison d’un problème de licence lié à l’utilisation incorrecte d’une bibliothèque AGPL
    • La fonctionnalité a été retirée afin de rétablir la conformité de licence pendant l’examen d’une autre implémentation

  • Configuration des proxys de confiance dans les conteneurs

    • Les anciens conteneurs Forgejo utilisaient REVERSE_PROXY_TRUSTED_PROXIES = * comme valeur par défaut
    • Si toutes les conditions suivantes étaient réunies, un utilisateur non autorisé pouvait usurper l’identité d’un autre utilisateur au moyen de l’en-tête X-WebAuth-User
      • Déploiement dans un conteneur basé sur Docker ou Podman
      • Configuration de [service].ENABLE_REVERSE_PROXY_AUTHENTICATION=true
      • Valeur par défaut * de [security].REVERSE_PROXY_TRUSTED_PROXIES laissée inchangée
      • Port web par défaut :3000 exposé à un réseau non fiable, permettant de contourner le proxy inverse d’authentification
    • v16 n’honore plus la configuration de proxy inverse dans ce type de configuration ; vous devez donc indiquer les plages d’adresses de proxy de confiance par lesquelles arrive le trafic
    • Exemple de configuration par variable d’environnement : FORGEJO__security__REVERSE_PROXY_TRUSTED_PROXIES=127.0.0.0/8,::1/128,172.16.X.X/X
    • Dans app.ini, configurez la même liste d’adresses dans REVERSE_PROXY_TRUSTED_PROXIES sous [security]

Ergonomie des dépôts et des organisations

  • Les notifications de dépôt peuvent être suivies séparément selon trois catégories : issues, pull requests et releases
    • Le backend de notifications repensé servira de base à des réglages plus fins à l’avenir
    • L’objectif est de donner aux utilisateurs le contrôle des notifications sans exposer un nombre excessif d’options
  • L’écran de migration de dépôt affiche la progression du déplacement par lots des issues et pull requests depuis la source, afin de vérifier si une opération longue est bloquée
    • La taille de lot par défaut est de 45 éléments, et le nombre minimal d’éléments pour afficher la progression est également de 45
  • Deux avatars réduits sont générés aux emplacements où la taille complète n’est pas nécessaire, afin de réduire l’usage de bande passante et les temps de chargement
  • Depuis la liste des membres d’une organisation, il est possible d’ouvrir directement une boîte de dialogue pour ajouter un nouveau membre et l’affecter à plusieurs équipes en une seule fois
  • Git vérifie et rejette plusieurs incohérences dans les objets reçus, afin d’éviter que le dépôt ne se retrouve dans un état incohérent ou corrompu
  • Les fichiers de hooks d’exemple de Git ne sont plus créés dans les dépôts backend, et les hooks Git communs à l’instance sont conservés de manière centralisée au lieu d’être dupliqués dans chaque dépôt
    • Cela économise environ 20 KiB par dépôt
    • Les fichiers d’exemple et les fichiers générés automatiquement en double dans les dépôts existants peuvent être supprimés en suivant le guide de mise à niveau
  • Correction d’un bug présent depuis v7.0.0 qui empêchait les nouveaux utilisateurs de voir l’invite à activer davantage de fonctionnalités de dépôt ; le réglage permettant de désactiver cette invite est aussi plus facile à trouver
    • L’invite « Enable more » n’apparaît que lorsqu’un administrateur ou le propriétaire du dépôt a explicitement désactivé certaines fonctionnalités du dépôt

Pull requests et revue de code

  • La liste des commits de la page de pull request adopte une nouvelle mise en page plus lisible et mieux adaptée aux tailles d’écran
    • Elle ne s’applique pour l’instant qu’aux pages de pull request, avec une extension progressive prévue aux autres écrans de listes de commits
  • Les revues multi-lignes permettent de relier plusieurs lignes modifiées à un seul commentaire de revue
    • En maintenant Shift, cliquez sur le bouton plus à côté de la première ligne, puis faites glisser jusqu’à la dernière ligne pour associer les lignes sélectionnées à un même commentaire
  • Correction de problèmes où des commentaires de revue apparaissaient dans un mauvais diff ou à une mauvaise position à l’écran, ou perdaient leur association avec le diff
    • L’ancien git blame pouvait mal retrouver la position lorsque le code ciblé par un commentaire avait été déplacé dans des commits ultérieurs
    • En interne, git blame --reverse est utilisé pour suivre les modifications du code jusqu’à sa position actuelle
    • La position des commentaires est calculée non seulement par rapport au HEAD de la pull request actuelle, mais aussi d’après la base et le head réellement consultés par le relecteur, ainsi que le commit du code affiché
    • Pour les lignes supprimées, Forgejo recherche le moment de la suppression et vérifie qu’elles sont également supprimées au même emplacement dans le diff actuel, puis place le commentaire ou l’affiche comme obsolète

Forgejo Actions et intégration JWT

  • Priorité d’exécution et gestion des workflows

    • Une exécution de workflow individuelle peut être marquée manuellement comme prioritaire, et Forgejo Actions la traitera avant les exécutions ordinaires
    • Lorsque c’est possible, Forgejo évalue directement les conditions if, sans envoyer la tâche au Forgejo Runner, ce qui permet de démarrer l’exécution plus rapidement
    • Les exécutions de workflows terminées, ainsi que leurs journaux et artefacts, peuvent être supprimés depuis l’UI ou l’API HTTP
      • Seuls les administrateurs du dépôt ou les jetons d’accès disposant du droit write:repository peuvent les supprimer
    • Les expressions cron prennent désormais en charge la syntaxe de fuseau horaire de GitHub, en plus du format existant CRON_TZ
    • Les checks ignorés, que les versions précédentes affichaient comme réussis, sont désormais affichés comme skipped à partir de v16

  • Authorized Integrations

    • Après l’ajout en v15 d’une fonction de génération de JWT utilisable par des systèmes externes pour l’authentification, v16 propose les Authorized Integrations, qui authentifient l’accès à l’API Forgejo et à Git au moyen de JWT
    • Elles peuvent être utilisées dans des Forgejo Actions locales, ou configurées avec des règles permettant à Forgejo de vérifier des JWT arbitraires
    • Lorsqu’un accès dépassant les permissions ordinaires de ${{ forgejo.token }} est nécessaire, il n’est plus nécessaire de configurer un jeton d’accès statique puis de le remplacer à l’avenir
    • Aucune fonction permettant aux auteurs de workflows de s’attribuer eux-mêmes des permissions inattendues n’est exposée
    • Elles peuvent être utilisées sur plusieurs dépôts Forgejo
    • Les systèmes externes satisfaisant aux exigences techniques peuvent accéder directement à l’API Forgejo et aux dépôts Git via l’Authorized Integration de l’utilisateur, sans secret statique entre systèmes
      • Les exemples incluent Amazon Web Services, GitHub Actions et GitLab CI/CD

Actions et API d’administration

  • Ajout d’une API permettant de récupérer les journaux d’une exécution complète de workflow ou d’une tâche individuelle
  • Des endpoints permettent de lister, télécharger et supprimer les artefacts
    • L’endpoint documenté pour téléverser des artefacts reste dans la liste des travaux à venir
  • Ajout d’une API pour annuler une exécution de workflow individuelle
  • /actions/run renvoie les informations de l’exécution de workflow à laquelle appartient le jeton automatique FORGEJO_TOKEN
  • Les autres changements d’API sont les suivants
    • L’heure de création a été ajoutée au modèle d’organisation renvoyé par plusieurs endpoints
    • La recherche de pull requests peut filtrer par nom de branche base et head
    • Les administrateurs d’instance peuvent lister, émettre et supprimer les jetons d’accès des utilisateurs
    • La liste des utilisateurs peut être filtrée par état 2FA

Durée de support et builds de test

  • Les versions majeures sortent tous les trois mois, et les versions correctives sont distribuées plus fréquemment selon la gravité des bugs ou correctifs de sécurité inclus
  • v16.0 est une version non LTS, prise en charge jusqu’au 29 octobre 2026
    • Le support de v11.0 LTS prend fin le 16 juillet 2026
    • v15.0 LTS est prise en charge jusqu’au 15 juillet 2027
    • v17.0 est prévue pour le 15 octobre 2026 et devrait être prise en charge jusqu’au 28 janvier 2027
  • Des builds quotidiens 16.0-test sont créés à partir des derniers changements de la branche de développement v16.0/forgejo et déployés sur l’instance de test

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • @pushcx, où est passé le lien suggest ? Je voulais proposer le tag vcs, mais je ne vois plus le lien sur aucun article

    • J’observe la même chose et j’aimerais en connaître la raison
    • Actuellement, le lien suggest apparaît sur cet article et sur la plupart des articles de la page d’accueil, et il n’y a aucun historique d’action concernant le compte sur https://lobste.rs/moderations. Cela ressemble à un bug

  • Merci à tous les contributeurs, en particulier à l’équipe de merge. Personnellement, je suis fier d’avoir contribué au correctif https://forgejo.org/2026-07-release-v16-0/#repository-units-hint

  • Ces derniers jours, j’ai configuré et ajusté une forge personnelle sur https://forge.l3x.in, tout en migrant progressivement depuis GitHub, et l’auto-hébergement de Forgejo a été une expérience très satisfaisante que je recommande vivement
    J’ai entendu dire que SourceHut était bien aussi, mais je ne l’ai pas essayé moi-même ; pour l’instant, je me concentre sur Forgejo

  • Je suis content de voir arriver les fonctionnalités de revue sur plusieurs lignes et de positionnement des commentaires de revue. À $JOB, nous n’avons pas de revue de code, donc je n’y suis pas habitué, et lors de revues de patchs soumis à des projets libres et open source, il m’est arrivé plusieurs fois de mal comprendre à quel bloc de code un commentaire faisait référence

  • J’attends beaucoup des paramètres d’abonnement granulaires. C’est une fonctionnalité que j’utilisais sur GitHub et qui me manquait énormément dans Forgejo
    Même sur GitHub, je souhaite depuis longtemps une fonctionnalité permettant de s’abonner lors de la création d’issues et de PR. Cela permettrait de suivre l’avancement de projets auxquels on contribue seulement occasionnellement, sans devoir se désabonner manuellement de 90 % des notifications sans intérêt
    J’ai ouvert une demande de fonctionnalité dans le dépôt Forgejo : https://codeberg.org/forgejo/forgejo/issues/13494

  • J’exploite Forgejo dans mon homelab depuis un moment et j’en suis très satisfait. J’ai migré environ 500 dépôts qui étaient sur Github.com, et le processus s’est fait avec très peu de friction ; Forgejo et les runners tournent dans k8s
    Le fait que Forgejo Runner utilise les mêmes définitions de workflow que GitHub Actions est particulièrement pratique : il m’a suffi de créer les bons labels sur les runners locaux
    Je n’ai pas encore décidé si je laisserai GitHub en lecture seule, si je le supprimerai ou si je le conserverai comme miroir équivalent. Dans tous les cas, je pousse désormais directement vers mon instance Forgejo plutôt que vers GitHub, et toutes les opérations sont beaucoup plus rapides, à l’échelle de quelques secondes