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.
Aller plus loin
- Le site officiel de gitlab (1532 clics)
- L'annonce de la version 2.0 (90 clics)
- Accéder à la démo de gitlab (836 clics)
- Le code source de gitlab (112 clics)
# mieux que gitweb
Posté par Daniel Castronovo (site web personnel) . É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 yanntech . Évalué à 0.
C'est certain, mais tu ne compare pas les même fonctionnalités ... à tester donc
# github
Posté par dufour olivier . É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 Larry Cow . Évalué à 5.
J'aime bien l'idée, mais j'ai deux questions :
[^] # Re: Mmmh
Posté par Bruno Michel (site web personnel) . Évalué à 3.
À ma connaissance, aucune forge ne propose ça actuellement.
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 Joris Dedieu (site web personnel) . Évalué à 5.
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 Johann Ollivier-Lapeyre (site web personnel) . É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 Joris Dedieu (site web personnel) . Évalué à 6.
Pour compléter voici un extrait du wiki de redmine que je trouve assez parlant :
http://www.redmine.org/projects/redmine/wiki/RedmineInstall
[^] # Re: Mmmh
Posté par nud . É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 cedric . É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...
[^] # Re: Revue de code et bug tracker
Posté par Bruno Michel (site web personnel) . Évalué à 4.
C'est prévu pour la version 2.1 qui sortira le 22 janvier.
# rythme de sortie
Posté par barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Questions
Posté par barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.