Salut journal,
Je viens donner des nouvelles de Gitlab ("lab", pas "hub"), que j'aime bien et qui grossit à vue d'œil. Dernièrement deux choses valent le coup d'être mentionnées:
il existe maintenant des paquets Debian pour installer son instance de Gitlab en un coup de cuillère à pot. Voyez la doc.
Exemple pour Debian 8 (Jessie):sh
wget https://downloads-packages.s3.amazonaws.com/debian-8.0/gitlab-ce_7.10.1~omnibus.2-1_amd64.deb
sudo dpkg -i gitlab-ce_7.10.1~omnibus.2-1_amd64.debla partie d'intégration continue (CI) a été grandement améliorée, la faisant ressembler à travis-ci (avec la conf dans
gitlab-ci.yml). Elle a été réécrite en Go, ce qui a comme avantage direct d'offrir des binaires d'installation pour linux, mac et windows. On peut utiliser des technos de virtualisation comme Docker et surtout, lancer plusieurs tâches en parallèle. Toutes les infos ici. Si aussi ça vous manque ou si vous avez d'autres requêtes, vous pouvez apporter votre voix et votre vote dans le forum.
Gitlab c'est en gros comme Github, mais un logiciel libre, que l'on peut installer soi-même, qui propose également des comptes gratuits sur gitlab.com (publiques ou privés, illimités). Il faudrait faire un comparatif poussé une fois, mais il est sûr qu'il y a de moins de moins de différences entre les deux. Je me souviens quand même d'une qui m'a récemment embêtée, c'est la fonction de recherche parmi tous les comptes Gitlab qui n'est pas assez complète. Avec Github je peux trouver des projets par plusieurs critères, ou chercher où est utilisée telle fonction de tel language.
De plus, ils ont récemment acquis Githost, qui propose de l'hébergement personnalisé de Gtilab et Gitlab CI.
En conclusion: si vous avez un projet personnel sur github qui n'a pas besoin d'effet communautaire mondial, venez tester sur gitlab.com ou git.framasoft l'importateur en un clic de projets github !
# Omnibus c'est hasbeen !
Posté par NiKaro (site web personnel) . Évalué à 9.
Il y a encore mieux maintenant, ils ont mis en place un dépôts, donc après l'avoir ajouté il suffit de faire un
apt install gitlab-ceet c'est bouclé ! Même plus la peine de se casser la tête pour les mises à jour.Cf. https://about.gitlab.com/2015/05/01/gitlab-on-debian-8/
[^] # Re: Omnibus c'est hasbeen !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
La version libre ne semble pas gérer les groupes via LDAP. Il y a un contournement possible ?
[^] # Re: Omnibus c'est hasbeen !
Posté par diorcety . Évalué à 1. Dernière modification le 07 mai 2015 à 10:58.
Enfin je ne suis pas le seul!
C'est sans animosité que je dis ça, juste un constat, mais c'est une fonctionnalité qui manque à la version "Communautaire", je pense notamment aussi à "Display merge request status for builds on Jenkins CI".
Je suis à la recherche d'une solution pour faire de la review de pull/merge request (visualisation du code, commentaire, compilation, suites de tests ainsi que le status) bref une partie de ce que fait github et gitlab édition entreprise.
Mon constat c'est qu'il y a beaucoup de solution mais aucune le propose en open source et complètement gratuitement.
Je pense aussi à la partie gitlab ci, c'est une bonne feature mais j'ai un peu du mal à mettre tout les œufs dans le même panier.
[^] # Re: Omnibus c'est hasbeen !
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Coté Gitlab, faut basculer coté payant.
Par contre, il y a Gitblit qui fonctionne très bien en combinaison de Jenkins, et qui est lui vraiment gratuit et vraiment Open Source (j'ai fait de la trad et des correctifs, on peut y contribuer).
Il y a avec Gitblit une fonctionnalité interessante où pour un merge de branche (d'une fonctionnalité, bug…), lié à un ticket, il faut 2 "approbateurs", donc par exemple un chef de projet et Jenkins.
[^] # Re: Omnibus c'est hasbeen !
Posté par Zenitram (site web personnel) . Évalué à 7. Dernière modification le 07 mai 2015 à 14:26.
basculer que du côté payant mais libre, ou il faut basculer du côté payant et non libre?
Payer est une chose, avoir un binaire sans source et sans droit de modification en est une autre.
(moi qui croyais qu'on aimait le libre ici… faut informer surtout si c'est libre ou pas, car ça peut être payant et libre comme ça peut être payant et non libre)
[^] # Re: Omnibus c'est hasbeen !
Posté par Daiko . Évalué à 1.
J'ai découvert Gogs récemment : http://gogs.io/. Je n'ai pas encore testé. Il est encore jeune et je ne sais pas si il peut prétendre à rivaliser avec Gitblit ou Gitlab.
[^] # Re: Omnibus c'est hasbeen !
Posté par dzecniv . Évalué à 1.
Gitblit: http://gitblit.com/ Java 7.
Pas moyen de tester en ligne et ils ne proposent pas de comptes, dommage.
[^] # Re: Omnibus c'est hasbeen !
Posté par Zenitram (site web personnel) . Évalué à 2.
https://about.gitlab.com/features/
"LDAP group synchronization (also compatible with Active Directory) : Entreprise Edition".
Ils ne cachent pas que la version Open Source est leur plaquette publicitaire mais si tu veux toutes les fonctionnalités : passe à la caisse et en non libre.
C'est du semi-libre.
Acheter la version entreprise ;-).
Ben oui, c'est plus ou moins proprio… Plus dans l'esprit proprio avec une version "light" et une version "entreprise".
Ca manque d'un équivalent de GitHub vraiment dans l'esprit libre, je croyais GitLab dans cet esprit mais en fait non :(.
[^] # Re: Omnibus c'est hasbeen !
Posté par Nairwolf . Évalué à -1.
Pardonnez-moi mon caractère naïf si je me trompe, mais…quel est le problème de ne pas avoir de github dans l'esprit libre ?
Github et Gitlab fournissent tout les deux un service, et ne sont pas totalement libres. Ce sont des hébergeurs, mais le code reste quand même sous la propriété de leur auteurs, non ? Git, par contre c'est libre. Et si j'ai bien appris ma leçon, il est possible d'avoir un serveur, et de développer à plusieurs en utilisant git, sur le serveur dédié.
Ceci est bien possible, non ? Dans ce cas-là, quel est le problème que github ne soit pas libre et que gitlab ne soient pas complètement libre ?
C'est l'interface graphique que vous voudriez qui soit libre ?
Merci.
[^] # Re: Omnibus c'est hasbeen !
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 07 mai 2015 à 20:55.
Euh… On parle de GitHub/GitLab, donc de tout ce que font ces logiciels, oui. Pas de Git.
Je ne comprend pas la question.
Internet Explorer fait du HTML5, donc le code du serveur HTML5 reste libre, pourquoi vouloir un navigateur libre à la place? Il peut être proprio, les données restent libres… On peut parler du non besoin d'avoir LibreOffice parce que Microsoft Office existe et peut exporter en RTF. enfin, c'est ce que tu dis.
Moi, j'aimerai bien une forge de la qualité de GitHub ou GitLab en libre!
(certes, GitLab "gratuit" me conviendrait déjà, j'y pense, mais je sais que dès que je voudrai un peu pousser la chose on me demandera de passer en non libre… Et je parle d'une fonctionnlité dans GitLab, pas dans Git)
[^] # Re: Omnibus c'est hasbeen !
Posté par Thomas Douillard . Évalué à 2.
À mon avis il cherchait à dire que c'est interopérable.
[^] # Re: Omnibus c'est hasbeen !
Posté par RyDroid . Évalué à 3.
GitHub fournit un logiciel en tant que service, une partie de l'informatique des utilisateurs de GitHub est donc contrôlé par ce dernier et ils dépendent d'eux. https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Pour le dépôt, il est certes facile de changer, mais le problème est toujours là. Pour le reste (bogues, wiki, pull requests, etc), ce n'est pas toujours aussi facile.
GitHub est également problématique à cause du JavaScript non libre. https://www.gnu.org/philosophy/javascript-trap.html
GitLab "Community" est libre. GitLab "Entreprise" est plus complet et propriétaire.
[^] # Re: Omnibus c'est hasbeen !
Posté par Nairwolf . Évalué à -2.
Ok, merci, je vois un peu mieux le problème que cela pose. En fait, c'est les fonctionnalités très user-friendly (issues, pull requests) qui sont très pratiques sur github, et qu'il serait intéressant d'avoir. Et qui ne seront pas avec un serveur dédié à git.
Est-ce que Launchpad est libre ? Parce que j'ai vu que récemment, Launchpad pouvait prendre en charge git : http://blog.launchpad.net/general/git-code-hosting-beta
[^] # Re: Omnibus c'est hasbeen !
Posté par Zenitram (site web personnel) . Évalué à -1.
Toi, tu es un petit jeune, grillé…
http://fr.wikipedia.org/wiki/Launchpad#Critiques
Donc oui c'est libre.
Maintenant, dit-nous si Launchpad fait ce que font GitHub/GitLab.
Il ne suffit pas d'avoir une fonctionnalité sur le papier (déjà, tu n'as pas parlé de ça), encore faut-il bien le faire.
Ici, par exemple en libre GitLab fait déjà beaucoup mais pas les groupes LDAP (c'est le sujet du fil), si tu conseilles un autre logiciel c'est que tu sais que ce logiciel fait les groupes LDAP, sinon… Merci de ne pas balancer n'importe quel nom au hasard, c'est lourd comme méthode de discussion "tu cherches x? je ne sais pas si ça fait x, mais essaye y pour le plaisir de perdre ton temps".
[^] # Re: Omnibus c'est hasbeen !
Posté par Yann 'Ze' Richard (site web personnel) . Évalué à 3.
Exact en effet :'(
Par contre y'a des API :
- http://doc.gitlab.com/ee/api/users.html
- http://doc.gitlab.com/ee/api/groups.html
Grâce à ca tu peux, moyennant un petit (ou moyen voire gros c'est suivant ton SI) travail, synchroniser tes groupes. Je n'ai pas regardé s'il y a possibilité de "hook" sur les créations de user dans Gitlab pour rendre cela plus dynamique.
Pour une organisation qui a un outil de gestion de groupe (type Grouper par exemple) ils peuvent aisément "push" les changements dans gitlab par exemple.
C'est pas natif du coup mais au moins ca reste une solution.
[^] # Re: Omnibus c'est hasbeen !
Posté par NilugeKiWi . Évalué à 1.
Gitlab a des "system hooks" pour tout ce qui n'est pas directement lié à des évènements git: http://doc.gitlab.com/ce/system_hooks/system_hooks.html; y compris pour la création d'utilisateurs.
[^] # Re: Omnibus c'est hasbeen !
Posté par flan (site web personnel) . Évalué à 4.
Gitlab utilise une base de données classique (postgres ou mysql). J'ai donc fait un petit script (avec l'ORM de Django vu que je maîtrise un minimum) qui écrit directement les utilisateurs et les groupes dans la base de données de Gitlab.
[^] # Re: Omnibus c'est hasbeen !
Posté par dzecniv . Évalué à 1.
Mince, j'ai loupé ça !! merci.
Quelqu'un aurait-il osé essayer cette grosse machinerie sur un olimex ?…
[^] # Re: Omnibus c'est hasbeen !
Posté par Anonyme . Évalué à 2.
Attention, ça ne marche pas avec apt-cacher-ng.
[^] # Re: Omnibus c'est hasbeen !
Posté par NiKaro (site web personnel) . Évalué à -1.
Il suffit de mettre
Acquire::http::Proxy::packages.gitlab.com "DIRECT";dans ton fichierapt.conf.# Des vrais paquets ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Le paquet de Jessie, c'est un vrai paquet ? Par vrai paquet, qui a de vrais dépendances avec les paquets débian, et qui installe le tout dans les répertoires standards ? (je n'ai pas de jessie sous la main pour vérifier)
Parce que la dernière fois que j'ai voulu installer le paquet d'omnibus (il y a 2-3 mois), j'ai vu qu'il foutait tout en vrac dans un répertoire /opt, y compris sa propre version de nginx, de ruby et cie. (ce qui est totalement débile en particulier pour nginx, quand nginx est déjà installé).
Bref, une installation de merde. J'ai continué à installer gitlab "à la main", et en installant les paquets debian dépendants
[^] # Re: Des vrais paquets ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 07 mai 2015 à 14:31.
Bah, il suffit d'ouvrir le paquet avec un bon logiciel (qui regarde le paquet, sans l'installer) pour voir où ça s'installe ;-).
bon, allez pour la curiosité :
199 objets dans gitlab-ce_7.10.1~omnibus.2-1_amd64.deb\data.tar.\opt\gitlab\embedded\bin\
(pg_xxx, git-xxx, redis-xxx, bunzip etc… ah ouais, quand même)
[^] # Re: Des vrais paquets ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
ok, donc le paquet deb fourni par gitlab, c'est du grand n'importe quoi.
à la limite sur wheezy, je pourrais comprendre qu'il veuille fournir leur propre ruby car Ruby 2 n'était pas dispo sur wheezy en standard. Mais pour le reste, je m'étonne d'une telle dépendance et cette volonté d'installer sa propre version.. surtout pour bunzip, postgresql, nginx….
[^] # Re: Des vrais paquets ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
À vrai dire, faire un paquet propre pour Gitlab, ça ne semble pas facile !
Il y a quelqu’un qui s’y essaye pour FreeBSD, et il s’en voit. Cf. https://www.mail-archive.com/freebsd-ports@freebsd.org/msg64637.html (et le reste du fil).
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
De toute manière, rpm et dpkg aurait du interdire d'écrire dans /opt afin de garder ce dossier aux installations manuelles…
[^] # Re: Des vrais paquets ?
Posté par mazarini . Évalué à 3.
C'est du manuel assisté :)
[^] # Re: Des vrais paquets ?
Posté par kna . Évalué à 5.
Et si j'ai un truc qui s'installe dans /opt (parce que c'est proprio, parce que c'est crade ou parce que c'est une version différente de celle installée par la distrib) mais que je veux quand même l'empaqueter pour gérer plus facilement le déploiement et les mises à jour ?
[^] # Re: Des vrais paquets ?
Posté par Marotte ⛧ . Évalué à 2.
C'est idiot. Quand t'installes un package custom qui ne provient pas des sources officielles de ta distribution ou encore de sources notoirement connues, il n'y a pas de différence d'avec installer un programme à partir de ses sources/binaires, téléchargées dans un tar.gz depuis un obscure site web quelconque…
Utiliser /opt ça permet de ne pas utiliser /usr/local, ce qui permet de ne pas utiliser une partition qui hébergerait /usr…, tu peux à la rigueur réserver /usr/local à des packages compilés à partir des sources officielles, mais dont tu as eu besoin de compiler avec d'autres options, par exemple.
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
On interdit le montage de /opt par NFS en autorisant les gestionnaires de paquetage d'écrire dedans. Les paquets crades devraient à la rigueur écrire sous /usr/local qui est de toute manière crade. Sinon, il n'y a aucun soucis pour mettre /usr/local sous un autre volume que /usr… j'ai pas bien compris tes arguments sur ce point.
[^] # Re: Des vrais paquets ?
Posté par Marotte ⛧ . Évalué à 2.
Oui effectivement. Je parlais d'un point de vue logique, pas technique.
/usr -> binaires fournis par la distrib
/usr/local -> binaires compilés à partir de sources fournies par la distrib
/opt -> ce qui ne rentre pas dans les deux premières catégories
Je ne comprends le rapport avec NFS… Peux-tu m'expliquer ?
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Sur un cluster par exemple, tu n'as pas forcément envie d'installer Matlab, Ansys… en local sur chaque poste. Tu as donc bien envie de les mettre sur /opt et de partager/monter ce dossier via NFS (voir monter en lecture seule). Or des paquetages écrivent sous /opt donc le dossier est difficilement partageable via NFS car quels noeuds va écrire dessus si tu déploie ton paquet ? Et si tu supprimes le paquet, c'est le merdier…
Bref, le seul moyen est de trouver un nom que pas grand monde utilise, genre /vol ou /mysoft et d'utiliser ce dossier à la place de /opt… C'est dommage car le premier paquetage qui écrira dessus cassera tout. Faut donc avoir un nom de dossier qui ne devienne surtout pas populaire !
En conclusion, la seule solution, à mon avis, serait que les gestionnaires de paquetages interdisent un dossier racine. Cela aurait du être /opt mais comme c'est trop tard à mon grand regret, il faudrait en trouver un autre et qu'ils se mettent tous d'accord pour l'interdire effectivement.
[^] # Re: Des vrais paquets ?
Posté par claudex . Évalué à 3.
Je ne comprends pas pourquoi tu ne peux pas faire /opt/shared partagé en NFS au lieu de partager /opt directement.
« 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: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Parce qu'on installe sous /opt/VENDOR ;-) Autant faire un /vol qu'un /opt/shared… En pratique, selon les postes, j'aurais aimé installer en local ou faire un montage NFS. Exemple : un noeud de calcul -> montage NFS, un portable utilisateur -> copie locale. /opt/shared, ça donne l'impression qu'on est en partagé…
Et puis on retombe toujours dans le même problème, si ce dossier devient populaire, il y aura un couillon qui fera un paquetage qui utilise ce chemin…
[^] # Re: Des vrais paquets ?
Posté par claudex . Évalué à 3.
Il te reste /$(pwgen 42 1)
« 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: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ah ah, excellent ;-)
# Vraiment libre?
Posté par diorcety . Évalué à 3. Dernière modification le 12 mai 2015 à 14:59.
J'ai fais un peu plus d'investigation sur ce GitLab et c'est bien ce qui me semblait.
Fait troublant pour un gros projet de ce type c'est qu'il n'y a pas de système de plugin(voir la demande).
La raison cité est "GitLab is open source, you can just create a project service and send a merge request to include it in the project. This avoids a lot of complication and security issues and guarantees that plugins are not broken in future versions."
C'est clair qu'ils vont sûrement accepter le plugin équivalent à celui qui vendent dans la version Entreprise (genre Jenkins CI).
Mais la raison principal est je pense que en faisant ça tu es obligé de signer leur "contributor license agreement". Je ne l'ai pas lu mais je parie qu'il parle de permettre à Gitlab de vendre et de mettre sous leur licence le code contribué. Donc il n'y a pas moyen de contribuer sous une autre licence(résumé en "GitLab is open source").
Je pensais rajouter un service pour voir le coverage de mon projet dans sonar mais franchement ça sera sans moi.
Faut t'il changer le texte du journal "Gitlab c'est en gros comme Github, mais un logiciel open source"?
[^] # Re: Vraiment libre?
Posté par flan (site web personnel) . Évalué à 3.
Mais d'un autre côté, il faut se mettre à leur place. Ils gagnent de l'argent en vendant leur licence entreprise, et il faut bien qu'elle garde des avantages par rapport à la version gratuite.
Personnellement, ça ne me choque pas, même si j'aimerais bien avoir la version entreprise gratuitement. Ils auraient très bien pu rester en 100% propriétaire.
[^] # Re: Vraiment libre?
Posté par diorcety . Évalué à 1.
Cela ne me choquerait pas non plus si il y avait un système de plugin, par exemple comme dans Intellij IDEA.
Mais la franchement c'est pousser le bouchon vraiment trop loin.
[^] # Re: Vraiment libre?
Posté par flan (site web personnel) . Évalué à 2.
Oui, ça ne te choquerait pas si en gros tu pouvais avoir le beurre et l'argent du beurre (vu que le but est clairement d'avoir les fonctionnalités de la version entreprise sans son prix).
Il faut plutôt voir l'autre aspect : ils auraient pu le garder totalement propriétaire comme Github, et ils ont quand même fait une version libre (même si légèrement incomplète).
Après, tu as toujours la possibilité de le forker (et de maintenir le fork, ce qui n'est sûrement pas évident), voire tout simplement de ne pas l'utiliser.
Et pourtant, je suis affecté par ce comportement (vu que j'avais dû patcher la version libre pour avoir une authentification Kerberos et ça m'arrangerait bien qu'elle soit prise en compte directement).
[^] # Re: Vraiment libre?
Posté par diorcety . Évalué à 1.
Non je ne veux pas spécialement des fonctionnalités de la version Entreprise. Juste un moyen propre d'ajouter des extensions qui me semble quand même élémentaire vue la quantité de services qui pourraient être intégré. C'est ce refus de ce système et l'argument associé que j'apprécie moyennement dans un projet qui se veut libre, à la vue de ce qu'il faut signer pour pouvoir faire intégrer quelque chose.
J'ai plus l'impression que c'est justement l'entreprise qui veut le beurre et l'argent du beurre. C'est à dire faire du commerce du produit tout en profitant de la contribution de la communauté qu'ils peuvent utilisé comme bon leur semblent.
Cela reste quand même un projet intéressant.
[^] # Re: Vraiment libre?
Posté par flan (site web personnel) . Évalué à 2.
Oui, mais ça permettrait d'avoir plus facilement les fonctions Enterprise. Après, tu peux rajouter un certain nombre de fonctions de façon détournée avec les webhooks, même si c'est loin d'avoir la souplesse de vrais plugins.
Je suis d'accord avec toi sur le fond, ça serait 'achement mieux avec des plugins, mais je trouve déjà pas mal ce que l'on a déjà =)
[^] # Re: Vraiment libre?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
A t-il été montré, via par exemple un certain nombre de projet, que cette stratégie est la bonne ? La stratégie du tout libre améliore grandement la diffusion du projet et n'empêche pas nombre d'entreprise de prendre du support. Les deux modèles existent donc.
[^] # Re: Vraiment libre?
Posté par flan (site web personnel) . Évalué à 2.
Pourquoi y aurait-il UNE bonne stratégie ?
Il y a plein d'entreprise différentes, avec plein de stratégies différentes pour gagner de l'argent, et que chacun considérera plus ou moins morales.
En l'occurrence, je ne trouve pas celle-ci choquante et elle me convient plutôt pas mal (même si elle pourrait encore plus me convenir s'ils mettaient en libre toutes les fonctionnalités de la pro).
[^] # Re: Vraiment libre?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est justement ma question. Quelqu'un a t-il déjà fait une étude permettant de dégager une ou plusieurs stratégies plus ou moins adaptées au contexte du projet ou, par exemple, la stratégie de la licence n'a que peu d'influence devant le charisme de l'équipe, l'effet de groupe… autour du projet ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.