Revival : Créer un miroir gitlab du dépot github

J’ai lu avec intérêt le topic Créer un miroir GitLab du dépôt GitHub

Qui se termine façon série américaine dont le budget a été coupé !

Je serais curieux de savoir si d’autres éléments ont été discuté ailleurs ?

Le topic datant de juillet 2016, des fonctionnalités vachement sympa sont apparues sur gitlab en plus des anciennes existant d’origine.

  • Gestion interne des sites statiques (gitlab pages)
  • Board d’issues
  • CI* qui permet de faire lancer tests et builds sur des machines à soi et de faire des deploy avec des variables sécurisées non stockées dans le code (éventuellement dans des docker)
  • Registry d’images docker par projets

et bien sûr les incontournables :

  • Gestion des groupes de projets et des droits de façon fine si nécessaire
  • Wiki
  • MR (équivalent des pull request) et revue de code au sein des MR
  • Protection de branches (quel niveau de droit permet de push / merge sur une branche)

etc…

C’est vraiment un bel outil et libre dans sa version communautaire.

Certains d’entre vous ont l’air très attaché à github, est-ce pour des fonctionnalités précises ? Pour la robustesse ? Pour la notoriété et la publicité du projet, plus simple sur github étant donné que c’est la référence ?

Dans mon entreprise, pour ce dernier point, nous avons pris le parti d’avoir de simples clones du dépot git ainsi que le dépot des releases dans github, tout le reste renvoyant sur notre gitlab interne. Cela fonctionne plutôt bien.

Le but n’est pas de remettre en cause tout l’existant, mais étant donné que le point avait été ouvert par le passé… :wink:

*: PS cela répond possiblement aux problématiques de travis CI aujourd’hui.

Aujourd’hui on utilise plutôt GitHub par défaut, et puis ça nous fait une porte d’entrée publique.

En réalité peu importe qu’on utilise GitHub ou GitLab, dans les 2 cas on a un outil centralisé. Sur GitLab ce serait potentiellement mieux car maîtrisé par nous, mais ça nous charge aussi de la maintenance.

Le plus important je dirais, c’est qu’on ait des copies du code source des logiciels et des copies de tous les tickets.

Après bon, beaucoup de personnes sont déjà habituées de GitHub pour ajouter un ticket ou faire une PR. Je ne sais pas si c’est plus simple sur GitLab, ni s’il est possible de réaliser ces opérations sur GH ou GitLab et d’avoir la répercussion des 2 côtés.

Non sur la partie annexe et notamment PR et issues, il n’y a pas de moyen simple que je connaisse de faire une synchro parfaite.

Quant à l’habitude, disons que l’interface gitlab n’est pas plus compliquée. Si on autorise la connexion par compte github, ça pourrait être assez simple pour les gens qui viennent de github.

Je ne connais pas de forge décentralisée, voire distribuée… Par contre, on a un outil sur lequel on a la main sans avoir à apporter notre confiance dans un acteur commercial du marché dont les intérêts sont divergeant de ceux de la communauté.

Quand à la question de la maintenance, on pourrait en parler lors des RML où je serai présent jeudi et vendredi. S’il y a volonté de la part de gens du projet de tenter (à nouveau) l’expérience, ça ne me gênerait pas de me charger de la maintenance de l’outil étant donné que je le fais déjà pour mon entreprise et pour mes projets personnels. Pour sécuriser tout ça, il serait utile qu’une autre personne soit ok pour s’impliquer et ait les connaissances nécessaires.

2 « J'aime »

J’ai profité des RML9 pour discuter avec plusieurs personnes d’entre vous sur le sujet de gitlab.

Ce qui m’a fait plaisir est que globalement, que ce soit sur le côté dépendance à une brique non maîtrisée et sûr le côté brique non libre au fondement d’un projet libre, toutes les personnes à qui j’en ai parlé ont été sensibles à l’idée et intéressées. Le débat est malgré tout ouvert si quelqu’un à des informations complémentaires qu’il souhaite donner.

Je commence à avoir une idée plus précise d’une approche que je vais essayer de vous détailler ici. N’hésitez pas à compléter, poser des questions et soulever les défauts.

  • Etat final cible :

    • Gitlab comme forge logicielle principale

      • Gestion des droits et des utilisateurs
      • Branches protégées
      • Gestion du merge
      • Gestion principale des issues
      • Gestion de l’intégration, des builds et du déploiement continu (eg : site web)
    • Github pour l’aspect social / vitrine

      • Clone du code
      • Import des “releases” (tags gitlab) et des artifacts associés
      • Connexion gitlab possible avec user github
      • Gestion secondaire des issues dont le process serait :
        • Un utilisateur peut créer un issue ici
        • Un développeur le constate et crée son équivalent dans gitlab (action manuelle)
        • Le développeur met dans github un petit message du genre ci-dessous puis ferme le ticket gitlab

        Notre tracking de bugs et fonctionnalités est à présent fait dans gitlab. Retrouvez votre ticket ici : https://git.duniter.org/tutu/toto/issues/131

Au niveau de l’administration et de la connaissance de l’outil, j’ai pris contact avec @Moul et @Tortue qui tous les deux se sont montrés intéressés pour tenter l’aventure avec moi et monter en compétence sur ces aspects.

A noter d’ailleurs que si ça prend bien, ce petit groupe pourrait aussi aider à certaines actions d’admin sys du serveur aujourd’hui réalisées par les devs core et clients à temps masqué.

Le chemin est assez long et il nous faudra je pense un certain nombre d’essais à blanc pour avoir une bonne compréhension / maîtrise de l’administration et de l’outil.

  • Eléments techniques à documenter

    • Installation et mise à jour avec docker
    • Configuration du backup
    • Restauration
    • Clone d’un dépot github
    • Mise en place de la connexion fédérée github dans gitlab
    • Création automatique des releases github avec les artifacts
    • CI/CD Gitlab pages pour le site duniter
    • CI / Build pour un des clients (si quelqu’un est motivé pour servir de beta testeur)
  • Actions immédiates à mettre en œuvre

  • Créer un ticket et un projet github pour faire le suivi des avancées de ce projet !

  • Installation d’un bac à sable permettant de faire du docker, avec le même système d’exploitation que le serveur duniter

  • Création d’un alias DNS vers l’ip de ce serveur du type git-sandbox.duniter.org

  • Installer et configurer une première version

Dans l’attente de vos retours !

4 « J'aime »

Le serveur de test est provisionné sous debian 8. C’est un Kimsufi à 10 UNL par mois. On va donc essayer que ça ne dure pas trop longtemps (quelques mois devraient suffire).

Je suis en train de le mettre à jour et de configurer Docker dessus.

@Moul et @Tortue avez-vous une préférence pour le login à utiliser sur ce serveur de test ?

Une connexion par clé SSH me conviens.

Et comme username ?

moul c’est bien.

1 « J'aime »

Gitlab est donc bien installé, avec la connexion avec github qui fonctionne bien.

Est-ce que chacun des devs principaux s’il a le temps peut essayer de s’y connecter (https://git-sandbox.duniter.org/users/sign_in) en utilisant la connexion github ?
Une fois fait, deux options possible. Ou me donner les droits sur un dépôt qui a pas mal d’issues ou bien tenter l’import vous même. Pour que je puisse faire une procédure, la première option serait peut-être plus pratique, mais si vous ne le souhaitez pas, pas d’inquiétude !

Aujourd’hui je vais faire la procédure de configuration du backup et remettre en forme les procédures déjà à disposition et les publier sur github.
Edit : le site duniter serait pas mal pour que je puisse tester aussi la CI / CD et gitlab pages !

3 « J'aime »

J’ai testé la connexion GitHub, ça fonctionne très bien.

Pour les dépôts, j’ai simplement ajouté les dépôts :

  • duniter/duniter
  • duniter/website_fr
  • duniter/website_en

en lecture pour le groupe duniter/GitLab. Est-ce que ce sera suffisant ?

Je testerai !

1 « J'aime »

GNOME se dirige vers GitLab.

2 « J'aime »

Bonjour à tous,
après une grosse période de travail, me voilà enfin en vacances.

Je vais donc pouvoir reprendre ce chantier (et recommander un serveur vu que le précédent à expiré).

Je vous tiens au courant !

3 « J'aime »

Après une grosse période de vacances, @florck se remet au travail !

5 « J'aime »

Les vacances des uns font le travail des autres !

Le précédent serveur a été supprimé du au fait que j’ai du faire bloquer ma carte de paiement en UNL suite à une usurpation d’identité sur Uber…

J’en ai commandé un chez AWS car j’ai un paquet de crédits gratuits.

L’adresse est 52.58.219.215 .

Si un admin genre @cgeek ou @Moul a l’occasion de mettre à jour l’entrée dns git-sandbox.duniter.org .

@moul, je t’ai recréé un compte moul, je t’envoie le passwd par MP.

Fait. Propagation effective sous quelques heures.

1 « J'aime »

J’ai un peu honte de moi… Quand on redémarre une instance ec2, vous saurez qu’il change l’ip publique… :’( Bon ben un coup pour rien du coup. J’ai attribué une “IP elastique” pour que ça tienne au reboot, et du coup c’est 52.57.170.38.

Vraiment désolé, c’est un peu la honte d’être mauvais comme ça.

Parce que tu crois être le seul à faire des erreurs !

1 « J'aime »

DNS mis à jour.

1 « J'aime »