Hébergez vos projets avec Gitlab

Posté par (page perso) . Édité par Malicia. Modéré par Xavier Claude. Licence CC by-sa
Tags :
33
23
déc.
2011
Gestion de versions

Gitlab est une application de gestion de dépôts git sous licence MIT. Elle permet d'héberger sur votre propre serveur des dépôts git avec l'interface web offrant tout le nécessaire pour vos projets : navigation dans le code source, suivi des demandes de bugs et d'évolutions (« issues »), wiki, gestion des droits d'accès par équipe, commentaires, notifications, etc.

D'un point de vue technique, c'est une application Ruby on Rails avec les dépendances suivantes : Ruby 1.9, sqlite3, git, gitolite (pour la gestion des droits d'accès aux dépôts git) et pygments (pour la coloration syntaxique du code).

L'équipe développant Gitlab travaille sur le rythme d'une version par mois et la version 2.0 vient juste de sortir. Celle-ci apporte des changements importants : les très attendues « merge requests », un tableau de bord revu, une gestion des permissions plus fines, notamment grâce à la prise en charge de gitolite, des améliorations graphiques, des fils Atom pour les commits et issues, etc.

  • # mieux que gitweb

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

    Je confirme, c'est bien mieux, plus complet/ergonomique que gitweb :)

    Je vais essayer ça tout de suite.

    Libre un jours libre toujours

    • [^] # Re: mieux que gitweb

      Posté par . Évalué à 0.

      C'est certain, mais tu ne compare pas les même fonctionnalités ... à tester donc

  • # github

    Posté par . Évalué à 7.

    euh c'est normal que leur source soit sur github et pas sur leur outil ;))
    Bon c'est encore loin de gitorious/github mais bon ca s'en rapproche...

  • # Mmmh

    Posté par . Évalué à 5.

    J'aime bien l'idée, mais j'ai deux questions :

    • gérer les "merge requests", c'est très bien, mais peut-on faire (ou répondre à) des requêtes sur une autre instance de Gitlab? Et si non, est-ce que c'est quelque-chose qui est considéré par l'un ou l'autre projet de forge?
    • est-ce que toutes les forges Git à la mode sont faites en Ruby? C'est chiant à installer...
    • [^] # Re: Mmmh

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

      gérer les "merge requests", c'est très bien, mais peut-on faire (ou répondre à) des requêtes sur une autre instance de Gitlab? Et si non, est-ce que c'est quelque-chose qui est considéré par l'un ou l'autre projet de forge?

      À ma connaissance, aucune forge ne propose ça actuellement.

      est-ce que toutes les forges Git à la mode sont faites en Ruby? C'est chiant à installer...

      Je suis un développeur Ruby donc je ne m'en rends pas bien compte : c'est vraiment chiant à installer ? À cause de Ruby ?

      C'est sûr que ce serait plus simple si ça pouvait s'installer d'un coup d'apt-get, mais les guides pour Ubuntu et Fedora me semblent assez simples.

      • [^] # Re: Mmmh

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

        c'est vraiment chiant à installer ? À cause de Ruby ?

        Quand tu as plusieurs instances, de plusieurs applis ROR sur le même serveur oui c'est vraiment chiant. L'une veut gems bidule et rails truc alors que l'autre dépend de active machin qui est en conflit avec le rails truc subcité. La seule solution propre est de passer par RVM. Autrement dit chaque appli son ruby, ses gems, sa version de rails et bon courage pour les mises à jours.

        • [^] # Re: Mmmh

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

          Effectivement, il y a les raisons cités, auquel je rajouterai la non connaissance des équipes systèmes (dans les boites où je suis passés...), et la difficulté, d'installer le bousin avec certaines distribs serveurs à cause des lib/gems qui ne sont pas les même que celles que le développeur du soft à prévu.

          A cela, tu peux rajouter que l'admin systeme lambda sait installer n'importe quel soft php ou java, même s'il n'a jamais développé dans ces langages.

          J'en connais, et j'en fait partie, qui se sont cassé les dents en entreprise avec des softs en RoR, où ils étaient le promoteur, et de facto l'installateur... et le mec qui perd en crédibilité quand tout foire (avec les données) lors d'une mise à jour, l'installation d'un autre projet ruby ou une migration d'OS. Perso, j'y réflechirai à 2 fois à l'avenir...

          Et pourtant, il y a des applis en or! Si j'étais dev d'un projet RoR visant une diffusion autre que confidentielle, je développerai en Ruby, mais viserait une compatibilité Jruby, et proposerait des war pour un déploiement direct dans un bon vieux tomcat. Voir même un bundle complet comme liferay ou icescrum le fait, avec un gros bouton vert Download.

        • [^] # Re: Mmmh

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

          Pour compléter voici un extrait du wiki de redmine que je trouve assez parlant :

          Ruby 1.9 is not supported yet. You have to use Ruby 1.8.x as stated above.
          RubyGems 1.3.7 or higher is required with following limitations :
          Rails 2.3.5 will fail with RubyGems 1.5.0 or later, stick to previous versions of RubyGems !
          Rails 2.3.11 will fail with RubyGems 1.7.0 or later, stick to previous versions of RubyGems !
          Rake 0.8.7 is required (rake 0.9.x is not supported by Rails yet)
          Rack 1.1.x is required, 1.1.0 has a bug with quotes (#8416). Database migration would fail with other version.
          Mongrel 1.1.5 needs a patch attached to #7688 to work fine with Rails 2.3.11. In case of upgrade, another issue may appear for some time after migration (#7857).
          I18n 0.4.2 is required for Redmine >= 1.0.5
          Rails 2.3.11 to 2.3.14 suffer from a major issue with sending mails to multiple recipients, see #8751 for details and solution.
          Rails 2.3.14 is a minor security release known to work fine with Redmine 1.2.x series (except for previous point) and can be used as a replacement for 2.3.11 (read config/environment.rb first).

          http://www.redmine.org/projects/redmine/wiki/RedmineInstall

          • [^] # Re: Mmmh

            Posté par . Évalué à 2.

            Le problème principal est probablement que la communauté ruby semble ne pas beaucoup donner d'importance à la stabilité des APIs et aux régressions au sein d'une même version majeure. S'ils étaient un peu plus coopératifs avec les distributions (qui ont besoin de la stabilité des APIs pour avoir un packaging efficace) tout serait réglé.

  • # Revue de code et bug tracker

    Posté par . Évalué à 1.

    Tous ces projets autour de git sont tres interressant. Trac etait bien, mais il mettait une barriere a l'entree plus eleve pour les nouveaux contributeurs. Envoyer un patch ete complique, alors qu'avec git et les merge request, participer a un projet devient trivial.
    C'est la ou les outils de revue de code deviennent tres important, gittorious et github permettent de faire des commentaires par ligne de code, est-ce gitlab le permet ? Il est aussi possible de noter un patch et quand celui-ci passe une limite, il est automatiquement merge upstream, est-ce que gitlab le permet ?
    Sinon avec svn et trac, on pouvait automatiser la fermeture d'un bug lors d'un commit. Est-ce que c'est possible de faire de meme avec git et gitlab ?

    Sinon le truc que je trouve tres domage avec en tout cas gittorious, c'est qu'il est absolument pas possible de retrouver les commentaires d'un patch une fois que celui-ci a ete applique upstream via la ligne de commande. Ca serait tellement plus sympa de pouvoir les obtenir lors d'un git log.
    Et de maniere symetrique, c'est domage qu'on ne puisse pas faire de la revue de code ou de la resolution de bug offline. Ca serait tellement puissant si on pouvait faire tout ca offline, recuperer par un git pull toutes les merge request, etudier chaque serie de patch, faire des annotations, tester la compilation et le resultat, puis une fois fini, pousser les commentaires et la note du merge request. Pour pas mal de developpeur, un outil web est nettement moins efficace que la ligne de commande...

  • # rythme de sortie

    Posté par . Évalué à 2.

    L'équipe développant Gitlab travaille sur le rythme d'une version par mois

    C'est très fréquent est ce que la mise à jour est simple ? Si ce n'est pas le cas ça constitue pour moi une barrière importante.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Questions

    Posté par . Évalué à 5.

    Je viens de tester rapidement la démo et j'ai une question : Qu'est ce que c'est que le mur et à quoi il sert ?

    Sinon pour le gestionnaire de bug : il est dommage à mon avis de ne pas pouvoir noter les bugs (un système de +1), ça permet de les trier et de savoir les quels sont les plus importants pour les utilisateurs.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

Suivre le flux des commentaires

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