Je viens vous demander votre aide : nous avons l’évolution #314 qui traîne depuis un moment sur GitHub (5 mois et demi !) dont le but est la création d’un miroir GitLab (l’équivalent libre de GitHub) du dépôt GitHub.
Cela fait suite à un billet de Carles Chenet « Le danger GitHub ».
Nous avions conscience de cette problématique du service centralisé, et que si jamais GitHub tombait, nous perdions l’ensemble des issues GitHub (anomalies et évolutions) en cours et closes, mais aussi le wiki. D’ailleurs il est arrivé plusieurs fois que GitHub soit indisponible depuis le début des développements, c’est assez handicapant.
L’idée donc, si quelqu’un veut tenter l’expérience, est de réaliser un tel miroir. Mieux, si vous y arrivez, on pourrait même tenter d’aller plus loin et faire en sorte que GitHub soit le miroir du dépôt GitLab. Là, ce serait le top, on aurait un lien bidirectionnel pour utiliser GitLab ou GitHub selon nos préférences.
Voilà, avis aux amateurs !
Bien entendu, je pourrais essayer de le faire moi-même, mais je préfère investir mon temps à développer le cœur du logiciel.
Tu peux communiquer directement ici, mais si tu préfères une communication instantanée il y a le salon XMPP. On n’y est pas connecté H24 7/7J, mais presque. Tu nous y trouvera sans problèmes.
Seulement le dépot git ? Disons que nous cherchons à mettre en place un service identique à GitHub (dépot git, bug tracker, wiki et webhooks), et plutôt en miroir dans un 1er temps afin de conserver notre fonctionnement actuel sur GitHub : GitLab permettrait surtout d’avoir une copie potentiellement fonctionnelle identiquement à GitHub.
Tout cela serait plutôt par étapes. Surtout si on peut basculer sur un usage majoritairement GitLab, où GitHub deviendrait le miroir.
On dispose d’un serveur dédié chez OVH, sur une Debian. Tu es actuellement dessus, ce forum y est hébergé tout comme http://duniter.org. On y fait donc ce qu’on veut, je suis celui qui possède le compte OVH et peut donc intervenir à tout niveau technique. @moul et @inso ont aussi un accès root à la machine. On y héberge aussi notre outil de traduction https://weblate.duniter.org, ainsi qu’un noeud Duniter (un miroir lui aussi !).
A noter qu’on est pas fermé à procéder autrement pour GitLab, selon les possibilités techniques.
Nous avons 36Go d’espace disponible actuellement. Par ailleurs nous utilisons Docker pour le forum Discourse, et nous avons peut-être un autre cloisonnement pour weblate (cc @Inso) mais non-Docker cette fois.
nous utilisons Travis CI et AppVeyor pour l’intégration continue et le packaging des logiciels (notamment Duniter et Sakia)
A priori, on ne peut pas trop se passer de Travis et AppVeyor facilement.
Pour les releases, on peut continuer à les déployer sur GitHub pour conserver de l’espace disque, mais ce serait bien aussi de pouvoir les déployer sur l’instance GitLab, quitte à supprimer manuellement les plus vieilles en cas de besoin d’espace disque.
Sinon sur la méthode, ça me paraît bien tu réaliserais quoi dans ces étapes ?
Concernant IPFS, ne connaissant pas le projet, je ne saurais répondre ! Et j’avoue qu’un bref coup d’œil ne m’a pas permis de bien comprendre le fonctionnement.
J’ai aussi découvert IPFS par ce post, en gros, si j’ai bien compris, c’est une sorte de nfs versionné sur P2P si tu veux (avec toutes les implications - décentralisation en particulier, je ne peux m’empêcher de faire le rapprochement avec l’excellent Symform qui est malheureusement en train de fermer ses portes à cause du rachat par Quantum)… chaque «machine» est un nœud P2P qui partage ses données avec les autres et qui peut récupérer les données des autres aussi. Il suffit de connaître l’UUID d’un nœud pour récupérer ses données (sachant qu’ils développent le pendant du DNS pour leur système). C’est un projet encore en plein développement, et se posent de mon côté plein de questions (sécurité, redondance et nettoyage de caches etc) mais je n’ai pas le temps de creuser plus que ça. Intéressant en tout cas et prometteur!
Pour faire simple, dans notre contexte, IPFS est comme mettre le dépôt GIT en torrent mais avec un tracker distribué. Tant qu’il restera un seeder quelque part dans le monde, le dépôt éxistera (en gros). Mais bon, c’est plus du wishlist que de la todolist. On en reparlera si ça devient concret. La sécurité est effectivement importante.
Pour travis-ci ça part mal, Gitlab Propose lui “GitLab Runner” https://about.gitlab.com/gitlab-ci/
Et les gens de travis sont catégoriques sur le fait qu’ils ne vont pas supporter gitlab: https://github.com/travis-ci/travis-ci/issues/5931Ceci est un blocage où il faut prendre une décision. Est-il pertinent d’ouvrir une discussion juste pour cette question ?
Pour appveyor ça semble bon : “AppVeyor has got built-in support for GitLab with OAuth, appveyor.yml, webhooks and commit statuses” … “Basically, the flow is the same as for other repositories - just add a new project, select “GitLab” then your repo. Webhook will be added automatically. Configure project on UI or add appveyor.yml with config to the root of your repo.”
Je peux pas vraiment m’engager à livrer des étapes, Je suis présentement sans contrat de travail donc c’est bon. Mais quand j’aurai un contrat, je devrai le priorisé. J’aimerais le faire au complet si mes horaires me le permettent. Contiens de cette contrainte, Je vais prendre un soin particulier à me documenter et resterai disponible pour la maintenance et/ou le changement de garde.
De toute façon, pour Travis et AppVeyor on peut conserver le fonctionnement avec GitHub en miroir j’imagine (ce n’est qu’une histoire de webhook sur git push si je comprends bien).
Et en cas de coupure de ces services, cela nous obligera simplement à réaliser nous même l’IC avec nos serveurs, ce qui sera coûteux et contraignant, mais pas impossible (je pense à Vagrant par exemple).
Pour la livraison des étapes : bien évidemment on n’attend aucun engagement de ta part ni de qui que ce soit, il s’agit de logiciel libre et de contributions libres. Mais c’est surtout pour connaître tes intentions et nous organiser en fonction.
Ceci dit, merci déjà pour l’apport en méthode, c’est une contribution effective et un sacré gain de temps pour moi si j’avais dû chercher !
Tiens bah justement, là tout de suite, GitHub déconne. Les push non affichés pendant au moins 3 minutes, et maintenant les Webhooks qui ne fonctionnent plus du tout !
J’ai installer et tester rapidement gitlab sur mon serveur. J’ai opter pour un instance docker finalement.
Je serais pret a faire un premier test d’import mais ils me manque des trucs cote github. Les instructions sont ici : http://0464.ca:5380/help/integration/github
mon email: fred {at] 0464 ca
Un dileme c’est presente, Gitlab a besoin d’ecouter sur le port 22 pour les pull et push de git, malheureusement sshd ecoute deja sur ce port . Apres recherche, il ne semble pas etre impossible de filtrer et fowarder les requetes ssh selon le domaine. Comme Workaround j’ai editer mon fichier local ~/.ssh/config Mais Il n’est pas realiste d’exiger ca de tout les contributeurs-trices. DONC 2 choses peuvent etre faites:
utiliser un 2e IP pour gitlab
Changer sshd de port pour laisser la place a gitlab. Le deplacer du port 22 au port 2222 par exemple, Ce qui forcerais les administrateurs-es du serveur a editer leurs ~/.ssh/config pour la maintenance.
Mon avis personnel - utiliser le port standard pour ssh est considéré comme insecure à cause des bots qui spam à la recherche de failles, donc ça ne peut de toute façon pas faire de mal.
J’ai pas garder le lien Le probleme vien de ssh. Gitlab ecoute sur le port 22 pcq c’est le standard. Mais le sshd du serveur ecoute deja sur le 22 pcq c’est le standard. Heureusement, Docker permet de faire une redirection et d’ecouter sur un autre port a l’exterieur du container. Dans mon cas j’ai utiliser :5322. ( docker run ... --publish 5322:22 .... ) Ce qui, a priori, devrais regler le probleme. du fait que gitlab docker ecoute maintenant sur :5322.
Mais Mon client ssh a la maison lui ne le sait pas. il essai quand meme le port 22. Et la, c’est le serveur qui repond.
Pour l’indiquer a mon client de se connecter sur 5322 la solution que j’ai utilise est d’ajouter a mon ~/.ssh/config:
Host gitlab.0464.ca User admin Port 5322 IdentityFile /home/border/.ssh/id_rsa
Pour moi ca va, mais ca me parais un facteur de decouragement a la contribution que d’exiger ca de tout les contributeurs.
Les options sont donc; soit de faire l’inverse ( faire ecouter gitlab sur le 22 pour et l’hote ailleur ).
ou d’uitliser un IP different.
(Je suis sur qui a aussi plein d’autres options funky et pas standard Mais j’ai pas trop envis de m’y embarquer)
@Moul avec multiple users ? Mon probleme c’est pas de faire le port foward mais la gestion des users entre le container et de l’hote. Ceci dit, Peut-etre (meme surement ) que j’ai manque qqch, je suis curieu de savoir comment tu a fait.
@Inso a un point, bien que ca reste de la securitee par l’obscuritee. ca evite tout de meme les bot opportunistes. Parcontre ca ne resiste pas a un portscan.
Je t’envoi une liste de questions en raffales pour sauver du temps.
tu réaliserais quoi dans ces étapes ?
Ceci est un blocage où il faut prendre une décision. Est-il pertinent d’ouvrir une discussion juste pour cette question ?
Le probleme vien de ssh. Gitlab ecoute sur le port 22 pcq c’est le standard. Mais le sshd du serveur ecoute deja sur le 22 pcq c’est le standard. Heureusement, Docker permet de faire une redirection et d’ecouter sur un autre port a l’exterieur du container. Dans mon cas j’ai utiliser :5322. (