Journal GitLab, mais encore ?

Posté par shingo (site web personnel) le 02 décembre 2014 à 09:22. Licence CC By‑SA.

Étiquettes :

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 Pi3R1k le 02 décembre 2014 à 09:55. É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 shingo (site web personnel) le 02 décembre 2014 à 10:04. É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 Pierre marijon (site web personnel) le 02 décembre 2014 à 10:24. É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 Laurent J (site web personnel, Mastodon) le 02 décembre 2014 à 11:55. É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 Grégory Soutadé (site web personnel) le 02 décembre 2014 à 09:56. É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 Grégory Soutadé (site web personnel) le 02 décembre 2014 à 12:08. É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 denxp le 02 décembre 2014 à 18:51. É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 Nonolapéro le 03 décembre 2014 à 14:27. É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 devnewton 🍺 (site web personnel) le 02 décembre 2014 à 10:01. É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 :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Y'a plus simple

Posté par falbala le 02 décembre 2014 à 10:07. Évalué à 5.

http://gogs.io/
- [^] # Re: Y'a plus simple
  
  Posté par shingo (site web personnel) le 02 décembre 2014 à 10:21. É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 dzecniv le 02 décembre 2014 à 11:29. Évalué à 2. Dernière modification le 02 décembre 2014 à 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 shingo (site web personnel) le 02 décembre 2014 à 12:27. É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 Anonyme le 02 décembre 2014 à 13:10. É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) ?
      - [^] # Re: Y'a plus simple
        
        Posté par shingo (site web personnel) le 02 décembre 2014 à 13:42. É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 Sufflope (site web personnel) le 02 décembre 2014 à 14:38. É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 shingo (site web personnel) le 02 décembre 2014 à 15:06. É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 cosmocat le 02 décembre 2014 à 13:44. É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 lockidor le 02 décembre 2014 à 14:22. Évalué à 1. Dernière modification le 02 décembre 2014 à 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 cosmocat le 02 décembre 2014 à 14:34. É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 Laurent J (site web personnel, Mastodon) le 03 décembre 2014 à 17:52. É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 shingo (site web personnel) le 04 décembre 2014 à 11:13. É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 Psychofox (Mastodon) le 02 décembre 2014 à 10:32. É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 claudex le 02 décembre 2014 à 21:54. É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 Psychofox (Mastodon) le 04 décembre 2014 à 11:26. É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 claudex le 04 décembre 2014 à 23:00. É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 Sébastien Maccagnoni (site web personnel) le 02 décembre 2014 à 10:36. É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.
- [^] # Re: Oui et non
  
  Posté par dzecniv le 02 décembre 2014 à 11:06. É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 Elfir3 le 02 décembre 2014 à 11:15. É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 dzecniv le 02 décembre 2014 à 12:21. Évalué à 3.
      
      Mais Bitbucket n'est pas un logiciel libre !
      - [^] # Re: Oui et non
        
        Posté par Elfir3 le 02 décembre 2014 à 13:44. É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 barmic le 02 décembre 2014 à 13:53. É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 Sébastien Maccagnoni (site web personnel) le 02 décembre 2014 à 11:49. É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.
    - [^] # Re: Oui et non
      
      Posté par dzecniv le 02 décembre 2014 à 12:26. É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 Cyprien (site web personnel) le 02 décembre 2014 à 12:31. É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 gregoire.s93 le 02 décembre 2014 à 11:36. É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
- [^] # Re: Tuleap
  
  Posté par dzecniv le 02 décembre 2014 à 12:30. Évalué à 1.
  
  Je ne trouve pas les sources, elles sont bien cachées.
  - [^] # Re: Tuleap
    
    Posté par Anonyme le 02 décembre 2014 à 13:11. Évalué à 1.
    
    Comme le chat. Il est dans son panier. Hum…
  - [^] # Re: Tuleap
    
    Posté par nemrod le 02 décembre 2014 à 13:36. Évalué à 2.
    Sur la page d'accueil : https://tuleap.net/ "Contribute code"
    Amène à : http://doc-en.tuleap.net/en/latest/#tuleap-developer-guide
```
 4.2. Git workflow

Development repository is hosted on http://gerrit.tuleap.net

You can checkout either from ssh or http: http://gerrit.tuleap.net/#/admin/projects/tuleap
```
    Sinon par ici : https://www.tuleap.org/try-and-go amène à https://tuleap.net/plugins/git/?group_id=101
    
    C'est donc récupérable via git (pas trouvé de sources sous forme d'archive effectivement).
    - [^] # Re: Tuleap
      
      Posté par Erwyn le 08 décembre 2014 à 10:16. Évalué à 1.
      
      En fait la raison pour laquelle les sources ne sont pas disponibles sous formes d'archives, c'est parce que l'installation de Tuleap se fait via des paquets RPM, vous trouverez la documentation d'installation ici. Si néanmoins vous voulez une archive, vous pouvez la télécharger via le miroir sur github.
# gitorious

Posté par lancelotsix le 02 décembre 2014 à 12:01. É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 Reihar le 02 décembre 2014 à 13:21. É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 phoenix (site web personnel) le 02 décembre 2014 à 20:22. É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….
- [^] # Re: Même chose sous Mercurial
  
  Posté par CrEv (site web personnel) le 02 décembre 2014 à 21:12. Évalué à 2.
  
  Indefero supporte mercurial
- [^] # Re: Même chose sous Mercurial
  
  Posté par Nicolas Casanova le 03 décembre 2014 à 09:26. Évalué à 1.
  
  Apparemment Kallithea s'est créé en réaction à la fermeture de RhodeCode (enfin, si l'on en croit wikipedia). C'est en python, ça gère Mercurial… Je me suis dit que ça pourrait t'intéresser.
# Autre alternative :Gitblit

Posté par El Titi le 03 décembre 2014 à 12:32. Évalué à 2.
C'est un projet que je suis de très près:
- très facilement déployable dans un cloud, y compris privé (ou je sais c'est du java)
- interface assez bien léché http://gitblit.com/screenshots.html
- interface en ligne de commande avancé pour la gestion des features branches http://gitblit.com/tickets_using.html
- modèle de pull request moins complique que Github qui oblige à utiliser dépots (le central, le clone du chef de projet, le fork sur Github et le clone localdu fork http://gitblit.com/tickets_overview.html
Enjoy …
- [^] # Re: Autre alternative :Gitblit
  
  Posté par El Titi le 03 décembre 2014 à 13:12. Évalué à 2.
  
  Sans oublier la dépêche qui me l'a fait découvrir:
  http://linuxfr.org/news/sortie-de-gitblit-1-4-x
# Software Factory

Posté par Frédéric Lepied (site web personnel) le 07 décembre 2014 à 19:46. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.