Journal GitLab, mais encore ?

17
2
déc.
2014

Me revoilà pour parler à nouveau de l'auto-hébergement, mais cette fois cela soulève quelques sombres interrogations qui subsiste dans mon esprit. Comme le titre l'indique, j'aimerais vous parler de GitLab et de savoir s'il y a véritablement un intérêt à préférer passer par cette solution plutôt qu'une autre et pourquoi pas communément sur GitHub. Forcément, lorsque l'on me propose un outil quasi similaire à ce dernier, je suis tout emballé rien qu'à l'idée de pouvoir le déployer sur mon serveur. Je dois dire que cela fait quelques semaines que j'ai découvert l'existence de GitLab, et malgré la présence d'un paquet sur l'AUR d'ArchLinux, j'ai trainé des pieds…

Je savais pertinemment que je devais un jour ou l'autre l'installer, un pas que j'ai franchi très rapidement, car je dois prochainement travailler sur un petit projet collaboratif qui ne concerne, malheureusement, pas le libre. D'autres parts, GitLab me permet de travailler sur mes projets personnels en cours dont quelques applications en PHP, mais aussi un jeu libre en C++. C'est assez plaisant d'avoir son propre espace de travail, même si je dois reconnaître que j'ai passé beaucoup de temps à installer GitLab. Avec du recul, l'installation s'avère assez simple dans l'ensemble, mais j'ai été victime d'un paquet foireux. Impossible de se connecter au git pour push un commit, mais après avoir bien épluché les forums, j'ai finalement trouver la source du problème : le fichier "secret" de gitlab et gitlab-shell étaient différents… Ce qui explique pourquoi je me faisais jeter comme un malpropre à chaque tentative de connexion à l'api. Mais passons…

D'un point de vue général, je suis très content de GitLab, il fait son travail, bien que je le trouve trop lourd par moment. Reste maintenant à savoir si je dois m'en remettre uniquement à cette application. Je me pose la question, car j'ai l'impression d'être isolé en oubliant les personnes avec qui je travaille. Là où je veux en venir, c'est que lorsqu'une personne rencontre un problème avec mon application, il doit forcément s'inscrire au préalable, idem pour proposer un correctif. Chose très contraignante pour beaucoup d'internautes, tandis que sur GitHub cela ne pose pas de problèmes puisque nous sommes nombreux à posséder un compte.

Puis je vois un autre problème assez préoccupant : la bande passante. Pour des petits projets où je partage uniquement le code source, pas de soucis, mais quand est-il si je décide de livrer les headers et les libraries dépendante pour faciliter la compilation ? Oui, en général cela ne pèse pas très lourd, mais lorsque je regarde la librairie Boost par exemple, rien que les headers pèsent plus de 100mo ! Je sais que sous Linux, on a tout à porter de main, mais sous Windows c'est un peu plus compliqué. Bah oui, il y a des gens qui compile sous Windows !

Alors je ne sais pas. Est-ce marginal aujourd'hui de déployer un GitLab à la maison ou est-ce au contraire une bonne pratique pour le futur ?

  • # Pourquoi gitlab ?

    Posté par . Évalué à 2.

    Quel a été ton choix de mettre gitlab , plutôt qu'une autre forge ? (mis à part le design)

    • [^] # Re: Pourquoi gitlab ?

      Posté par (page perso) . Évalué à 1.

      Disons que c'est la première chose que j'ai trouver sur Google et comme ça ressemblait énormément à GitHub, j'ai pas cherché plus loin. Après est-ce qu'il y a mieux, je ne sais pas, c'est à voir :)

      • [^] # Re: Pourquoi gitlab ?

        Posté par (page perso) . Évalué à 5.

        Il y a effectivement de nombreuse autre alternative (gogs, gitolite, etc…), mais aucun ne semble présenté tout les avantages de gitlab :

        • tout en un -> pas obliger de géré les droits d'accès au dépôt a la main
        • la maturité -> c'est très stable, et très facile a installé
        • le dynamisme du développement -> un peut trop dynamique peut-être

        On peut aussi lui reprocher sa lourdeur, et oui en RoR on mange de la mémoire au petit matin.

        Ce n'est que mon avis après plus de 1 ans d'utilisation, mais gitlab est une très bonne solution, il ne reste plus que la gestion d'autre VCS pour être complète.

        Ps : hésiter pas a passé sur le chan #jeuxlibre sur freenode :)

    • [^] # Re: Pourquoi gitlab ?

      Posté par (page perso) . Évalué à 2.

      En ce qui me concerne, j'ai adopté Gitlab parce que c'est ce que j'ai trouvé de plus complet avec une interface et des fonctionnalités modernes.

      Je l'utilise pour les projets de mes clients et les projets internes. J'ai aussi installé gitlab-ci pour lancer des tests auto et déploiement automatique. (Je n'utilise pas Jenkins car je trouve que c'est une horreur sans nom au niveau interface, d'un autre temps, et super lourdingue à l’exécution, et si tu veux faire un truc pas supporté par un plugin, c'est la méga galère à configurer).

      Par contre pour les projets open-source, j'utilise Github. C'est plus facile pour les contributeurs, et je n'ai pas envie de mélanger projets privés/projets publics. Pour le déploiement continue de mes projets open-source (packages, site web etc), j'ai installé Strider-cd sur mon serveur.

  • # Bande passante

    Posté par (page perso) . Évalué à 3.

    Si tu as des gros paquets (binaires, headers…) à fournir avec tes sources, tu peux donner un lien externe, voire même proposer un script pour les télécharger automatiquement.

    Pour l'inscription, c'est le même problème pour chaque service que tu proposes (inscription, pas d'inscription -> SPAM, OAuth…).

    • [^] # Re: Bande passante

      Posté par (page perso) . Évalué à 2.

      Personnellement, j'utilise le défunt inDefero qui est plutôt léger. C'est limité, mais ça fait le minimum requis !

      • [^] # Re: Bande passante

        Posté par . Évalué à 3.

        Moi aussi j'aime bien cette forge. C'était ma toute première.

        En parlant de ça, est-ce que quelqu'un sait ce qu'est devenu Loïc d'Anterroches ?
        Il trainait un peut ici et faisait(fait ?) des devs assez sympas.

        • [^] # Re: Bande passante

          Posté par . Évalué à 2.

          Il avait lancé un projet nommé baregit mais qui semble totalement à l'arrêt puisque le site ne répond plus tout comme sa page perso.

  • # gitlist + service

    Posté par (page perso) . Évalué à 3.

    Gérer un site avec des inscriptions et des écritures, c'est assez lourd. J'ai adopté le compromis autohébergement en lecture, service externe en écriture avec gitlist et github.

    On pourrait appeler ça le CQRS hosting :-)

    http://devnewton.bci.im

  • # Y'a plus simple

    Posté par . Évalué à 5.

    • [^] # Re: Y'a plus simple

      Posté par (page perso) . Évalué à 1.

      Merci, je suis en train de regarder la démo et j'avoue que ça m'intéresse beaucoup. C'est léger et assez simple, mais parfaitement fonctionnel.

    • [^] # Re: Y'a plus simple

      Posté par . Évalué à 2. Dernière modification le 02/12/14 à 11:30.

      Gogs: Go Git Service. Une copie très ressemblante de github, avec pour l'instant moins de fonctionnalités que Gitlab (au moins pas de gists/snippets, pas de wiki), je vois aussi moins de services (Gitlab: Gitlab CI, Jira, Jenkins etc, Gogs: rien ?).
      Et pas de merge requests sur Gogs ? pas de protection de branche et autres petits trucs utiles.

      • [^] # Re: Y'a plus simple

        Posté par (page perso) . Évalué à 2.

        Je viens d'essayer rapidement Gogs, assez facilement à mettre en place, même trop… Au début je pensais que c'était une application web, mais en fait c'est vraiment un truc complet. De plus il y a un paquet sur AUR, alors c'est vraiment vite fait. Pas besoin de lire un wiki, un petit nano sur le fichier app.ini et une proxypassreverse dans apache et le tour est joué !

        Ce que j'aime c'est l'interface bien épurée, même s'il y a nettement moins de fonctionnalité ça me convient, car c'est avant tout très rapide. GitLab c'était pas très réactif, dès que je fais un petit git push origin master, j'entendais déjà le disque gratter comme pas possible. J'ai également pu remarquer que je n'ai pas d'erreur lorsque je fais un push, tandis qu'avec GitLab j'avais sans cesse la même erreur sans que j'ai pu réussir à la résoudre.

        Après, je ne pense pas avoir besoin d'un truc très professionnel, c'est vraiment histoire d'avoir un petit espace de travail où je peux partager les sources de mes projets. J'avoue qu'un petit Wiki ne serait pas de trop, mais ça ne doit pas être très complexe à mettre en place, donc je pense que ça arrivera tôt ou tard, en tout cas c'est un petit projet bien sympa !

        • [^] # Re: Y'a plus simple

          Posté par (page perso) . Évalué à 1.

          Les erreurs avec GitLab, ça se corrige très bien.

          Alors on est pas sur le forum mais bon, c’est quoi ta version ? Ruby compilé ? Gems à jour ? Et puis… c’est quoi ton erreur en fait ? Tu push en SSH ou HTTP(S) ?

          Love – bépo

          • [^] # Re: Y'a plus simple

            Posté par (page perso) . Évalué à 1.

            Je push en http, voici le résultat :

            Counting objects: 74, done.
            Delta compression using up to 8 threads.
            Compressing objects: 100% (73/73), done.
            Writing objects: 100% (74/74), 104.92 KiB, done.
            Total 74 (delta 4), reused 0 (delta 0)
            remote: GitLab: An unexpected error occurred (redis-cli returned 1).
            To http://git.genku.net/shingosan/x-blaster-dominator.git
            * [new branch] master -> master

            A chaque fois il me marque : remote: GitLab: An unexpected error occurred (redis-cli returned 1).

            • [^] # Re: Y'a plus simple

              Posté par (page perso) . Évalué à 2.

              Quelle est ta commande exacte ?

              Tu ne pousserais pas énormément de refs d'un coup (par exemple un import initial d'un projet existant) ? Ils passent les refs créées à redis (pour les post-traitements tels qu'indexation, création d'activités dans le flux…) en construisant un appel en ligne de commande à redis-cli au lieu d'utiliser une lib redis native, dans un post-hook, et si la ligne générée dépasse la limite max pour une ligne de commande, le noyau l'envoie bouler. Sauf que comme c'est un post-hook c'est trop tard le commit est déjà fait.

              Plus de détails sur https://gitlab.com/gitlab-org/gitlab-shell/issues/10

              • [^] # Re: Y'a plus simple

                Posté par (page perso) . Évalué à 1.

                J'ai essayé pleins de fois des dossiers vides ça me faisaient pareil :

                mkdir folder
                cd folder
                git init
                touch README.md
                git add README.md
                git commit -m "first commit"
                git remote add git remote add origin http://git.genku.net/shingosan/x-blaster-dominator.git
                git push origin master

                bien sûr j'ai supprimé et recrée le repo avant et j'ai toujours cette erreur. Ça me gêne pas plus que cela, car il fait quand même son boulot…

        • [^] # Re: Y'a plus simple

          Posté par . Évalué à 3.

          J'avoue qu'un petit Wiki ne serait pas de trop

          Comme gogs et autre github affiche très bien les fichiers markdown, peut-être peux-tu plutôt versionner des fichiers markdown dans un répertoire nommé "wiki".

          Je préfère même cette solution à un wiki car tout est versionné et dispo à travers git! (on parle bien d'un outil de gestion de dépôts git, non!?! ;) )

          PS: par contre, le fait qu'il n'y ait pas de "pull request", c'est vrai que c'est bien dommage pour cette petite pépite…

          • [^] # Re: Y'a plus simple

            Posté par . Évalué à 1. Dernière modification le 02/12/14 à 14:22.

            Je préfère même cette solution à un wiki car tout est versionné et dispo à travers git! (on parle bien d'un outil de gestion de dépôts git, non!?! ;)

            Justement, les wikis de Gitlab sont en fait des dépôts git et sont donc versionnés :)

            • [^] # Re: Y'a plus simple

              Posté par . Évalué à 3.

              ouais, sous github c'est la même chose. Mais du coup, tu as 2 dépôts à maintenir pour chaque projet.

              En plus, là, tu as ton wiki synchronisé avec tes sources, ce qui me parait un avantage….

              • [^] # Re: Y'a plus simple

                Posté par (page perso) . Évalué à 4.

                je dirais plutôt un inconvénient selon moi, surtout si il y a plusieurs utilisateurs.

                un wiki, c'est censé être modifié très souvent, le contenu bouge etc. Cela veut aussi dire qu'une modification dans une page = un commit (que ce soit dans un dépôt git ou un autre système d'archivage).

                Résultat(1) : on se retrouve avec des centaines de commits (dont beaucoup ce sont des petites corrections d'orthographes ou autres). Et bien souvent, les utilisateurs ne mettent pas de "message de commit" (y compris moi, par flemme), donc on se retrouve avec des commits ayant le même intitulé par défaut.

                Si le contenu du wiki est dans le même dépôt que le code source, on se retrouve alors avec un historique complètement illisible. Ce qui annihile tout intérêt de versionner le code source.

                La documentation dans le même dépôt que le code source, pourquoi pas (je le fais bien pour slimerjs), mais faut pas que ce soit un wiki (c'est à dire, modifiable par une interface web). Et faut que ce soit une doc qui évolue en même temps que le code, donc très proche du code. Par exemple, une doc de référence (api etc) ok. Pour des tutoriaux ou manuels : je préfère un dépôt à part, car au final ils ont leur vie propre, et n'ont pas le même rythme de vie (par exemple, pour la documentation d'une lib, on va écrire les tutoriaux qu'une fois que l'api est relativement stable, et pas au fur et à mesure, sinon on risque de réécrire des parties du tuto 50 fois -> perte de temps).

                (1) ceci est une constatation que je fais à partir de wikis que je possède ou possédait, ouvert à plusieurs personnes.

      • [^] # Re: Y'a plus simple

        Posté par (page perso) . Évalué à 1.

        Bon finalement je ne sais pas si je vais rester sous GOGS, car ce n'est pas vraiment fonctionnel. J'ai détecté pas mal de problèmes dont l'un me gêne un peu. Il s'agit des tar générés automatiquement, sauf qu'une fois le fichier récupéré, il s'agit en réalité une archive ZIP… Donc quand quelqu'un va tenter le télécharger, il va sûrement s'énerver et penser que je suis du genre à faire n'importe quoi derrière mon écran.

  • # login via openid

    Posté par . Évalué à 4.

    Pourquoi ne pas permettre le login via un provider openid ? Entre google, fb, twitter et j'en passe ça ne devrait plus être un facteur limitant conecernant l'ouverture aux autres personnes.

    À priori ça peut se faire avec gitlab d'après une brèbe recherche:
    http://eric.van-der-vlist.com/blog/2013/11/23/how-to-customize-gitlab-to-support-openid-authentication/

    • [^] # Re: login via openid

      Posté par (page perso) . Évalué à 3.

      Entre google, fb, twitter et j'en passe

      Dans ta liste, seul Google est provider OpenID à ce ce que je sache.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: login via openid

        Posté par . Évalué à 2.

        oui j'ai mélangé OAuth et openid, m'en suis rendu compte et prié très fort pour que personne ne s'en rende compte. C'est manifestement raté ;-)

        • [^] # Re: login via openid

          Posté par (page perso) . Évalué à 3.

          Ah mais tu m'as fait perdre du temps pour vérifier que ça n'avait pas changer. J'exige un remboursement :)

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Oui et non

    Posté par (page perso) . Évalué à 4.

    Salut,

    Mon avis sur Gitlab est assez simple…
    Oui en entreprise, pour les développements internes, etc.
    Non à titre perso, où GitHub est bien plus accessible, orienté communauté etc. Exactement pour les raisons que tu évoques.

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

    • [^] # Re: Oui et non

      Posté par . Évalué à 2.

      Si on n'a pas besoin d'effet publicitaire de masse de Github, alors autant utiliser l'hébergement proposé par Gitlab. On peut même y créer des projets privés. https://gitlab.com/

      • [^] # Re: Oui et non

        Posté par . Évalué à 3.

        Sinon pour des projets privés il y a aussi bitbucket qui n'est pas trop mal. Si mes souvenirs sont bons on peut avoir des équipes jusqu'à 5 personnes pour des petits projets.

        • [^] # Re: Oui et non

          Posté par . Évalué à 3.

          Mais Bitbucket n'est pas un logiciel libre !

          • [^] # Re: Oui et non

            Posté par . Évalué à 2.

            Et alors ?

            • Gitlab n'utilise pas nécessairement le code libre mis à disposition
            • Le fil de discussion porte sur l'accessibilité et le trait communautaire, pas sur le coté libre de gitlab.
            • tiramiseb n'a pas choisi le coté libre de gitlab pour le développement perso
          • [^] # Re: Oui et non

            Posté par . Évalué à 7.

            Encore une fois quand tu utilise du logiciel comme un service, le fait qu'il soit libre ou pas n'a pas d'intérêt ni de sens (tu n'a aucune des liberté du logiciel libre). Ce qui est intéressant avec le SAAS, c'est :

            • la libération des données : puis-je récupérer mes données et dans quels formats ?
            • quelles garanties j'ai dans l'utilisation qui est fait de mes données ?

            Si tu regarde sous cet angle là, tu remarquera par exemple que beaucoup de logiciels libres ne sont pas très bons (souvent il n'y a pas de moyens de récupérer ses données et on oppose le fait qu'il suffit de faire un export de la base pour les sortir (donc inutilisable dans le cadre d'une solution mutualisée et utilisation d'un format difficilement réutilisable)).

            Je ne sais pas ce que valent gitlab et bitbucket à ce sujet là (pour ce qui est du code il n'y a pas de problème évidement.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Oui et non

        Posté par (page perso) . Évalué à 1.

        Quand j'évoque GitLab, je parle bien sûr de son installation sur une machine à soi (comme indiqué dans le message d'origine).
        Quand j'évoque GitHub, je parle d'un hébergement public, que ce soit GitHub ou autre - GitHub restant le plus populaire.

        https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

        • [^] # Re: Oui et non

          Posté par . Évalué à 1.

          Justement c'est ce que je ne comprends pas, tu fais un lien entre 2 choses différentes: tu dis "oui à Gtilab pour les petits projets, sinon Github". Or non, si Gitlab est trop lourd à héberger chez soi, on peut se faire héberger par eux. C'est aussi un moyen d'aider le projet.

      • [^] # Re: Oui et non

        Posté par (page perso) . Évalué à 1.

        C'est ce que j'ai fait avec un petit projet il y a deux mois. Je l'ai hébergé sur gitlab en privé et j'y vois tout les avantages : Aucune installation et si je veux l'autohéberger par la suite pour diverses raisons, il n'y a aucun problème.

  • # Tuleap

    Posté par . Évalué à 3.

    Bonjour,
    essaye ça : https://tuleap.net/
    y'a git, jenkins, un chat, la gestion des droits de Git.
    Et beaucoup d'autres choses

  • # gitorious

    Posté par . Évalué à 8.

    Dans les outils assez similaires à github, on a aussi gitorious, qui a l'avantage d'être publié sous AGPL. Je dois avouer que je ne l'ai jamais déployé, et je suppose que c'est plus ou moins aussi gourmand que gitlab en resources. Je ne l'ai utilisé que de manière très superficielle, mais en gros ça fait le taf.

    Sinon, pour revenir sur la question posée, pour ce qui est des projets auto-hébergés, j'utilise gitolite. On n'a pas d'interface graphique (à moins de déployer un gitweb). Ça se limite à gérer les droits d'accès mais dans mon cas c'est suffisant (je conçoit qu'on ait besoin de plus). Il faut dire que je collabore essentiellement avec moi même pour les projets hébergés à la maison… ;)

    Pour la question des fichiers un peu trop volumineux pour ta connection, tu peux utiliser le fait que git est décentralisé. Un dépot "principal" à la maison sur lequel tu travailles, et un clone chez gitorious ou github pour «déporter la charge». C'est en gros ce que fait Qt.

    • [^] # Re: gitorious

      Posté par . Évalué à 1.

      J'utilise gitolite, c'est super pour de petites installations. C'est très rapide à déployer, simple à configurer, et apparemment fiable (je n'ai pas tenté de pourrir mon serveur mais je n'ai pas rencontré de problème non plus). Au début, le fait que le projet ne s'hébergeait pas lui-même m'a fait un peu douter mais après utilisation, je suis satisfait. En plus, c'est la rache-compliant.

  • # Même chose sous Mercurial

    Posté par (page perso) . Évalué à 2.

    Je cherche la même chose mais pour Mercurial.

    J'utilise Rhodecode (dans sa dernière version libre) avec un trac à coté. Mais j'aurais préféré un truc tout intégré comme gitlab.

    Par contre j'utilise Mercurial.

    J'hésite du coup à basculer sur bitbucket, ou à utilier hg-git et gitlab….

  • # Autre alternative :Gitblit

    Posté par . Évalué à 2.

    C'est un projet que je suis de très près:

    Enjoy …

  • # Software Factory

    Posté par (page perso) . Évalué à 0.

    Une autre alternative: http://techs.enovance.com/7276/software-factory-enters-beta-and-is-released-as-an-open-source-project

    La solution reprend le workflow de développement d'OpenStack avec gerrit, jenkins, zuul, etherpad et ajoute redmine à la place de launchpad.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.