Pagure, la forge logicielle qui stocke tout dans le dépôt git!

J’avais découvert cette forge il y a longtemps, mais je ne me souvenais plus du nom.

Je suis convaincu que les références des commits (numéros de tickets), ne doivent pas pointer vers un numéro généré par UNE instance de forge logicielle qui, une fois en fin de vie, rendra ces numéros obsolètes et ces références inutilisables.

Cela rend les commits du dépôt dépendant d’une installation complète d’une forge logicielle qui doit être maintenue jusqu’à la fin de vie du dépôt. Autant dire que c’est mission impossible.

git-bug permet de stocker les tickets dans le dépôt, ainsi que les commentaires et les identités (utilisateurs). Il manque néanmoins la gestion des pull-requests dans le dépôt et on n’a pas (encore) la convivialité du site web complet d’une forge logicielle.

pagure semble être la solution.

C’est une forge logicielle légère apparemment comme les autres (avec moins de fonctionnalités cependant), mais qui a la bonne idée de tout stocker dans le dépôt !

Elle stocke :

  • La documentation (bon, on avait pas besoin d’elle pour mettre la doc dans nos dépôts, mais bon…)
  • Les tickets (c’est le prérequis minimum pour ne plus dépendre de l’instance de la forge).
  • Les pull-requests (là on est aux anges, on a tout dans le dépôt).

Pour info, c’est codé en Python et il semble que c’est la forge officielle pour la distribution Fedora !

https://pagure.io/docs/pagure/

Je vais installer et tester cette forge en local pour Sakia et je vous ferai un retour.

Articles avec différents aspects de réflexions à ce sujet :

Les projets Debian, GNOME et KDE utilisent GitLab comme forges logicielles.

2 J'aimes

J’ai feuilleté la doc de Pagure et ça ne supporte pas les CI gitlab, ils ne documente une CI que pour jenkins, non merci quoi… Pour l’avoir utilisé au boulot je trouve que jenkins est une plaie :confused:

Et puis il y a plein de petites features intégrées a Gitlab que j’apprécie énormément ou/et qui me font gagner du temps :

  • Static Git-powered pages
  • Built-in Container Registry
  • Built-in CI/CD
  • Subgroups: groups within groups
  • Git LFS 2.0
  • Granular user roles (Code, Issues, Wiki etc)
  • Confidential issues
  • Comment reactions
  • Lock Discussion

Et bien d’autres que j’oublie. Perso j’ai testé Gitea, Gogs, et d’autre forges encore, et il n’y a que Github et Gitlab qui me satisfassent :slight_smile:

1 J'aime

Et comment je fais pour déplacer les tickets et les merge-requests du silo GitLab Duniter pour les utiliser ailleurs ? Même le silo gitlab.com ne peut pas les importer correctement !

Pour le dépôt, c’est distribué, c’est du git, c’est pensé pour ça, pas de problème. Pour les données « méta » on assiste à une bataille des forges pour s’accaparer les données d’un maximum de projet.

Or les données « méta » sont des données « personnelles » intimement liées au dépôt. La liberté d’en jouir comme de son code est à défendre. Je pense qu’il est grand temps de récupérer ces données dans le dépôt pour les synchroniser de façon distribuée avec le code et ainsi respecter la liberté de distribution si chère à l’esprit du libre.

Le projet n’est pas de changer de forge pour Duniter, mais de proposer, dans les dépôts sur lesquels je travaille, le maximum de données liées.

Sakia a maintenant son Dockerfile dans le dépôt pour reproduire la CI dans une image Docker prête à l’emploi sans besoin de passer par la forge. Si j’arrive à aller au bout de ma démarche, quelqu’un qui clonera le dépôt aura le maximum de données et sera autonome : image CI, tickets, pull-requests, playbook Ansible, etc.

1 J'aime

Merci @Moul, très intéressantes ces réflexions.

Where possible, when we have to update our tooling, we will attempt to refactor our tooling to be forge agnostic, allowing our Communities the choice of storing their code on Gitlab or continuing to use pagure.io

Chez Centos/Fedora/RH/…, ils ne sont plus en capacité d’améliorer Pagure au niveau de GitLab sans impacter le développement de leurs projets, donc ils basculent sur GitLab. Ce qui me paraît sage.

Je note que dans leur roadmap, il chercheront à rester « forge agnostic », comme je cherche à le faire pour mes projets. Ainsi, on peut utiliser la meilleure forge en fonction des besoins, sans perdre la main sur les données.

@elois, toi aussi tu as souffert avec Jenkins ? :sweat_smile: Les runners GitLab, sont évidemment ce qu’il y a de mieux à ma connaissance pour un workflow fluide et efficace (et peuvent être reproduit si besoin avec un playbook Ansible en local).

2 J'aimes