Tous les 22 du mois, une nouvelle version de la forge logicielle Gitlab (Community Edition pour la version libre et Enterprise Edition pour la propriétaire) est publiée. Celle‐ci est très grosse et contient notamment une fonctionnalité attendue : une vue kanban pour les tickets.
GitLab.com a été mis à jour : dépôts illimités publics ou privés, importation depuis d’autres forges, miroir sur ou depuis GitHub, pages GitLab pour votre site, solution d’intégration continue…
Les changements majeurs
Vue kanban pour les tickets
Cette méthode présente les tickets sous des colonnes, par exemple : « à faire », « en développement », « en test », « prêt » ou « déployé ».
Illustration :
Présentation vidéo :
https://www.youtube.com/watch?v=UWsJ8tkHAa8
Il s’agit de la première livraison de la fonctionnalité, alors des améliorations (et pas des moindres) sont déjà dans les fourneaux :
- plusieurs vues kanban par projet ;
- une vue au niveau d’un groupe ;
- un bouton pour voir ou cacher les tickets fermés ;
- un bouton pour créer un ticket depuis cette vue ;
- trier les tickets dans une colonne ;
- chercher parmi toutes les listes ;
- ou encore possibilité d’enlever la colonne backlog.
Notons que les deux premiers points (plusieurs vues et une vue pour un groupe) sont destinés à l’édition entreprise de GitLab (et donc aussi à la version en ligne gitlab.com), pas à sa version communautaire.
Cela est‐il suffisant pour remplacer votre Kanboard (MIT), Wekan (MIT), Taiga (AGPL), Trello (propriétaire) ?
Notons que GitHub a vite réagi et propose maintenant une fonctionnalité ressemblante, à la grande différence près que leur tableau ne se base pas sur les tickets.
Résoudre les conflits de fusion depuis GitLab
Peut‐être pas pour les gros conflits, mais enfin :
Commander GitLab depuis les commentaires (slash-commandes)
Inspirés par les tchats, Slack ou autres, ils ont ajouté leur version de commandes qui permettent de commander GitLab en écrivant une commande (qui commence par une oblique — slash — /) dans un champ texte, au lieu de faire ces actions à la souris.
Dans la capture suivante, l’utilisateur crée un ticket et spécifie les étiquettes et la version de publication (milestone) avec ces commandes (et l’auto‐complétion) :
Liste des commandes :
http://docs.gitlab.com/ce/user/project/slash_commands.html
Intégration de l’EDI en ligne Koding
Nous voilà avec la possibilité de coder dans son environnement de développement intégré en ligne avec Koding.
Il nous permettrait même d’utiliser notre éditeur favori (à l’heure où j’écris ces lignes, cela n’a pas été déployé sur gitlab.com).
Vidéo de présentation :
https://www.youtube.com/watch?v=3wei5yv_Ye8
Résoudre les discussions en cours dans les demandes d’intégration
Lorsque l’on propose une demande d’intégration — merge request —, on peut discuter dans le diff du code, ligne par ligne. Cela peut être difficile à suivre, alors il est maintenant possible de marquer une discussion comme résolue.
Par conséquent, un bouton permet de passer d’une discussion non résolue à une autre.
Graphes pour visualiser son intégration continue
GitLab fournit clef en main une solution de CI (Intégration Continue). Une configuration pouvant devenir assez complexe, il est maintenant possible de la visualiser sous forme de graphe :
L’éditeur de code intégré permet de plier des parties de code
Il fait du repli de code (code folding) et améliore sa coloration syntaxique :
Badge de couverture de code
GitLab peut maintenant générer un badge qui montre le pourcentage de couverture de test du code :
Pour plus d’informations, voir la documentation.
Mattermost 3.3
GitLab est livré avec Mattermost 3.3, une alternative libre à Slack.
Et plus…
Vous pouvez tout lire dans les notes de version !
Aller plus loin
- Journal à l’origine de la dépêche (287 clics)
- Notes de version GitLab 8.11 (266 clics)
- Framagit (298 clics)
# Kanboard ou kanban?
Posté par n.rigaud . Évalué à 6.
Hello,
je suis heureux de voir apparaitre cette vue, qui me semble très utile.
Mais j'ai une remarque sur la forme, j'ai toujours eu l'impression qu'on parlait plutôt de vue kanban. Cela me perturbe d'autant plus que je suis utisateur de Kanboard et que j'ai tendance à associer ce terme spécifiquement à ce logiciel.
A+
[^] # Re: Kanboard ou kanban?
Posté par CrEv (site web personnel) . Évalué à 4.
Oui, c'est un board kanban si on veut, mais kanboard est un logiciel. D'ailleurs ils appellent ça "issue board" dans les release notes de gitlab.
[^] # Re: Kanboard ou kanban?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Kanboard ou kanban?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 20 septembre 2016 à 13:53.
le titre est toujours avec le nom du logiciel, ainsi que "plusieurs vues Kanboard par projet ".
(et je confirme : moi aussi j'ai pensé à une intégration avec le logiciel libre kanboard et pas compris que ça ne parle pas de lui à proprement parler)
[^] # Re: Kanboard ou kanban?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Config recommandée
Posté par damaki . Évalué à 3.
Des gens auraient testé la community avec du hardware moins costaud que ce qui est préconisé ? Je me vois difficilement mobiliser 2 Go de RAM pour un serveur git avec quelques services en plus pour 5 utilisateurs. Ils ont l'air de vivement déconseiller avec 1 Go de ram (ce qui me paraît déjà énorme, soit dit en passant).
En attendant, j'utilise Gitbucket qui fait l'affaire, tourne pour quasi rien en ressources et bientôt un Kanboard dédié, en attendant de trouver des softs léger pour les autres features.
[^] # Re: Config recommandée
Posté par Flyounet (site web personnel) . Évalué à 2.
Bah !? Tu veux pas utiliser 2 GiB de RAM et tu lances du java…
[^] # Re: Config recommandée
Posté par CrEv (site web personnel) . Évalué à 2.
C'est un peu plus que ca, non ?
Et d'ailleurs, avec ou sans mattermost ?
[^] # Re: Config recommandée
Posté par Julienng . Évalué à 8.
Une alternative légère qui pourrait t'intéresser : gogs. Egalement open-source, elle est développé en go. Par contre, cette alternative ne propose pas autant de fonctionnalité que gitlab
[^] # Re: Config recommandée
Posté par damaki . Évalué à 1.
Vu que je ne souhaite ni utiliser un LDAP, ni des utilisateurs Linux, je l'ai volontairement mis de côté. Monter un LDAP pour 5 utilisateurs, je trouve que c'est de l'overkill et je ne suis pas fan d'utiliser du PAM pour des logins applicatifs. Mais ça reste moins pire que d'autres, en fouinant j'ai vu un serveur git+web qui stockait les mots de passe en MD5, en 2016… Hélas j'ai oublié le nom de cette abomination.
En tous cas, merci.
[^] # Re: Configrecommandée
Posté par Juke (site web personnel) . Évalué à 2.
Pourquoi ?
[^] # Re: Config recommandée
Posté par DerekSagan . Évalué à 2.
La solution la plus simple reste la solution mutualisée: gitlab.com: c'est gratuit, c'est pas ta ram, c'est toujours à jour, et t'as les fonctions payantes pour rien.
Mais ton code est chez eux, donc tu vas pas pouvoir y mettre du soft secret défense.
# Réaction de Github
Posté par rdhlnn . Évalué à 2.
Github a été titillé par la concurrence, et a sorti en réaction au progrès de Gitlab un "nouvel univers".
Il semble encore avoir une longueur d'avance, pas forcément technique mais communautaire. La force de github reste sans doute son aspect "réseau social", et Github tente d'attirer le chaland de multiples façons.
Mais avec git (peut-être encore plus qu'avec d'autres technologies), le changement de plate-forme peut avoir lieu encore plus vite…
[^] # Re: Réaction de Github
Posté par El Titi . Évalué à -1.
Vi enfin entre Github et un projet qui fait de l'open-source washing (Contribuez, on est des gentiiiiils et nous on garde le beurre), je vois pas la différence. Autant prendre l'original !! Et les alternatives purement open-source ne manquent pas. Un peu comme la double licence AGPL/proprio qu'un certain habitué nous ressert régulièrement.
Sinon pour ceux qui vont hurler, Github, c'est Electron, Atom, libgit2… sans double licence. Gitlab, à part récupérer les contributions des autres en gardant une marge d'avance, ils font quoi pour le libre ?
Sinon, pour les spécialistes, si on contribue en open-source à réimplémenter leur feature proprio, on risque pas de se prendre un procès ?
Accessoirement, Mattermost, leur partenaire a exactement le même modèle.
Pas que je sois contre, chacun a le droit de vivre. Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence. Bref, sans moi !
[^] # Re: Réaction de Github
Posté par Anonyme . Évalué à 8.
Il publie un outil complet qui te permet de répliquer ces fonctionnalités où tu veux, comme tu veux, sans dépendre de leurs serveurs.
demande à framasky qui a implémenté en version libre les pages statiques jusqu'alors dispos uniquement dans la version entreprise : cf. journal
Je ne comprends pas ce qui te fait dire cela.
[^] # Re: Réaction de Github
Posté par El Titi . Évalué à -3.
Exemple:
Ou encore l'intégration LDAP qui je crois est réservée à l'edition pro …
Encore une fois, je comprends que chacun ait le droit de vivre de son travail. Mais expliquez ce qu'il y a de plus respectable à dire:
Si tu veux utiliser mes services hébergés chez toi, payes (tu n'auras pas les sources).sion c'est gratos pour un usage public
et
Si tu veux utiliser tous mes services chez toi payes. Pour les sources tu peux m'aider mais je conserve un avantage commercial sur toi. Toi tu reverses, moi non. Quelle différence au final avec une licence non libre sur du contenu telle que la CC-BY-NC. C'est de la pure hypocrisie.
Github étant contributeur open-source par ailleurs je me permets de répondre à l'auteur du commentaire qui semble avoir un parti pris.:
Le jour où Framasoft grandit, fédère des contributeurs et diverge du core au point que la version commerciale de Gitlab ne pourrait suivre, on en reparlerait ok ?
Bref, je maintiens: open-source washing
[^] # Re: Réaction de Github
Posté par Framasky (site web personnel) . Évalué à 6.
Tu crois mal : on l'utilise sur Framagit (car au départ notre gitlab était pour un usage interne). C'est l'utilisation de plusieurs LDAP qui est proprio.
En fait, si, tu peux avoir les sources de la version proprio : https://gitlab.com/gitlab-org/gitlab-ee :-)
Oulà, pour ça, faudrait qu'on diverge du core… et c'est vraiment pas notre volonté : on aurait bien du mal à suivre l'upstream pour intégrer les nouvelles fonctionnalités tellement ça va vite.
Comme Framasoft n'est pas une association de codeurs, on va plutôt encourager à contribuer upstream ou à faire un fork, mais on ne s'en occupera pas (et il faudrait vraiment qu'il y ait une truc de la mort qui tue pour qu'on passe au fork).
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Réaction de Github
Posté par benja . Évalué à 0.
Je crois qu'il parlait du modèle de github. Son argument étant tant que gitlab n'a pas de communauté d'utilisateurs-développeurs forte, le fait qu'il soit libre ne le différencie pas vraiment de github. Par ce qu'il serait stupide pour une organisation d'investir dans de la RD pour au final se retrouver à maintenir son propre fork. Vous semblez confirmer ce point de vue, au niveau de votre organisation.
On peut se demander aussi si ce constat est du à un manque de la demande ou à une à une offre volontairement bridée. En d'autres mots, est-ce que les clients "pros" demandent simplement une solution clefs-en-main sans réel besoin d'une solution complètement customisable; ce que pourrait être gitlab si il y avait un processus de développement communautaire non pipé (note: interprétation de "je conserve un avantage commercial sur toi"; personnellement je n'ai pas d'opinion éclairée sur ce sujet: j'évite l'un comme l'autre ;-) ).
[^] # Re: Réaction de Github
Posté par Zenitram (site web personnel) . Évalué à 3.
Dit moi juste : à part garder le nom dans les sources, quel droit ont-ils de plus que toi sur le code libre qui t'empècherait de concurrencer leur version entreprise? J'en vois aucun (licence MIT), le problème est seulement tes compétences. de quel avantage commercial parles-tu donc?
bref, je maintiens : tu fais du bashing gratuit; c'est franchement malsain.
[^] # Re: Réaction de Github
Posté par El Titi . Évalué à 4.
Tout le monde a le droit de se tromper. Merci de ne pas y prêter des intentions et les vaches seront biens gardées
[^] # Re: Réaction de Github
Posté par cpm . Évalué à -2. Dernière modification le 22 septembre 2016 à 11:15.
N'empêche qu'il y a effectivement deux versions : CE qui est libre et EE qui n'est pas libre, et que la version EE contient des fonctionnalités en code privateur.
Et quand on regarde l'histoire de GitLab, ce n'est pas rassurant du tout de constater qu'ils vont dans le mauvais sens : à l'origine, c'était 100 % libre et petit à petit de moins en moins. Quelle confiance leur accorder pour l'avenir ?
Et quand on lit ça :
Comment ne pas se dire qu'ils sont en incohérence avec les valeurs du libre ?
De plus, si tu connais leur annonces officielles, tu t'aperçois que cette news LinuxFr est faite d'énormes copier/coller venant de GitLab, comme par exemple : https://about.gitlab.com/2016/08/22/announcing-the-gitlab-issue-board/
On peut légitimement se poser la question de l'intérêt d'une news qui reprend juste la pub officielle.
Donc oui, la question du open-source washing se pose vraiment.
[^] # Re: Réaction de Github
Posté par Zenitram (site web personnel) . Évalué à -1.
Je t'invite à relire le commentaire auquel tu réponds.
Et d'arrêter d'utiliser ce mot à la con (désolé pas d'autre mot) car le code en question ne te prive d'absolument rien du tout (tu peux faire exactement la même chose, même plus, quand tu as ce code que quand tu l'as pas).
Et 100% de ce qui était avant libre est toujours libre.
Tu dis qu'avoir 100 libre + 10 pas libre est "dans le mauvais sens" par rapport à 10 libre. Excuse-moi, moi je vois "dans le bon sens" (on a 90 en plus pour le libre).
Tu n'aimes pas l'ajout de code non libre alors que tu peux code toi-même la chose (en libre ou pas, GitLab ne te bloque aucune possibilité de les concurrencer dans leur même modèle), soit, mais appeler ça open-source washing de près ou de loin est juste de la bêtise d’intégriste (mais vu le mot que tu utilises pour du code non libre : ce n'est pas étonnant ces mots dès qu'il y a un peu de code non libre, le libre ne t’intéressant pas, cracher sur x t’intéressant bien plus).
El Titi a eu l'honnêteté de reconnaitre son erreur (il s'est trompé dans la licence, en pensant à une licence qui fait que le libre n'est qu'un produit d'appel pour vendre le code libre en non libre, donc que la valeur est de passer le code libre en non libre, alors que GitLab vend du code en plus pas libre), lui (il n'avait pas utilisé le mot "privateur", ça doit aider aussi).
[^] # Re: Réaction de Github
Posté par Framasky (site web personnel) . Évalué à 4. Dernière modification le 21 septembre 2016 à 08:01.
Et je suis pas le premier à l'avoir fait (il y a qq'un d'autre qui avait fait un gl-pages, mais j'ai préféré coder un truc plus basique et plus simple).
A priori, ça ne les dérange pas. Rien n'interdit d'ajouter des fonctionnalités via les webhooks ou d'utiliser l'intégration continue, bien au contraire. Et tant qu'on ne leur pique pas leur code proprio…
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Réaction de Github
Posté par Zenitram (site web personnel) . Évalué à 6.
D'habitude j'irai dans ton sens, en disant que le libre sert de produit d'appel pour te vendre la version proprio que personne d'autre ne peut faire (j'adore les "gentils libristes" qui disent faire de la GPL "pour que le libre reste libre le proprio c'est mal" et qu'ils vendent une version proprio "pour faire vivre le libre promis", ils oublient qu'en pratique ils gardent le monopole sur cette possibilité comme par hasard celle qui fait du fric sur le projet)
Mais tu attaques le mauvais projet : avec GitLab, tout le monde peut faire exactement le même business que GitLab, car gitLab n'interdit pas de faire comme eux (c'est du MIT, et non du GPL)
Ton attaque n'a donc pas lui d'être : GitLab joue le jeu et ne garde aucun droit que pour eux.
Tant que tu ne pompes pas de code proprio (donc comme tout projet), aucun risque, c'est libre.
C'est complètement mensonger : la code libre et libre, et ils te laissent libres de faire comme eux comme business model.
Sérieux, la je ne comprend pas ton attaque, le libre est respecté, le modèle méritocratie aussi, tout le monde est libre de la même chose, ici.
On n'est absolument pas dans le modèle "GPL pour le libre et donc que moi qui peut vendre en poprio, le libre n'est qu'un produit d'appel pour te fourguer ce dont j'ai le monopole".
Je n'ai pas hurlé la dessus mais sur une attaque contre le projet lui-même.
Mais si tu veux jouer à ça : je ne vois pas le rapport, gitHub garde la partie proprio au chaud, et n'offre aucune version utilisable en libre. Donc GitLab propose quand même bien mieux que GitHub en terme de premier démarrage si tu veux entrer en compétition avec eux. gitHub fait le gentil mais fait bien attention à ce que tu ne puisses pas facilement les concurrencer, alros que GitLab fait le nécessaire pour que si ils sont mauvais, tu puisses concurrencer.
Sérieusement, tu ne vois pas la différence entre gitHub et GitLab, entre les dual licence copyleft et dual licence copyfree?
[^] # Re: Réaction de Github
Posté par El Titi . Évalué à 6. Dernière modification le 21 septembre 2016 à 22:28.
Toutes mes confuses alors ! J'étais persuadé qu'il s'agissait d'AGPL
Je retire mes propos.
[^] # Re: Réaction de Github
Posté par CrEv (site web personnel) . Évalué à 3.
C'est pas plutôt en réaction à https://github.com/dear-github/dear-github ?
Un peu comme la dépêche qui dit "Notons que GitHub a vite réagi et propose maintenant une fonctionnalité ressemblante", j'aimerais bien une source qui indique c'est en réaction. Certes côté timing c'est quasi en même temps, presque trop pour que ce soit une réaction justement.
Maintenant ces remarques n'enlèvent pas le fait que c'est une bonne chose qu'il y ait de la concurrence, ça force toujours à aller un peu plus loin. Et gitlab garde une avance avec leur CI pour le moment.
[^] # Re: Réaction de Github
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Pour certains, c'est surtout la mise en place du management chez github (qui avait auparavant une structure hiérarchique très plate) qui a permis ça. C'est plus probablement un mélange de tout ça et il est clair que la compétition avec Gitlab force Github à sortir de nouvelles fonctionnalités. Tant mieux.
[^] # Re: Réaction de Github
Posté par CrEv (site web personnel) . Évalué à 2.
Ça m'intéresse ça, tu aurais des liens ?
En fait je me demande en quoi rajouter du management fait que des features sortes ? C'est hyper intéressant comme question (d'autant plus que je suis dans une boite ultra plate ;-) ).
[^] # Re: Réaction de Github
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Pour les liens, 2 avis assez contradictoires :
Globalement, je pense que les structures plates marchent très tbien dans notre domaine pour des sociétés assez petites (jusqu'à 20 personnes). Ensuite, ça peut continuer à marcher mais ça peut aussi très vite déraper. A priori, Valve s'en sort très bien. Par contre, chez github, il semblerait que ça soit devenu très problématique. Mais c'est dur à dire, surtout maintenant qu'ils ont des investisseurs et qu'ils sont devenus, du coup, beaucoup plus opaques.
# Kanban board
Posté par cluxter . Évalué à 3. Dernière modification le 21 septembre 2016 à 10:12.
Pour l'instant, lorsqu'on ferme une "Issue" via un commit + merge request dans la branche principale, elle apparaît toujours dans les colonnes du kanban board au lieu d'être dans la colonne "Done".
Ce comportement est en train d'être modifié. Un filtre va être rajouté pour pouvoir masquer par défaut les issues qui ont été marquées comme fermées dans les commits, et on pourra les afficher si on le souhaite, et un point rouge indiquera lesquelles ont été fermées. De cette façon, on conserve le même comportement qu'actuellement (ce qui permet de conserver l'information comme quoi l'issue n'est pas passée par les étapes intermédiaires pour arriver jusqu'à "Done") mais on ne pollue plus la vue avec des issues qui ne doivent plus être résolues.
Le rapport de bug est ici et toujours ouvert, donc j'imagine que ce ne sera pas intégré d'ici demain : https://gitlab.com/gitlab-org/gitlab-ce/issues/21691
Vivement le 22 octobre donc !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.