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é…
*: 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.
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 : Sign in · GitLab
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
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 ?
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 !
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.
