Gitlab 6.4 de nouvelles options de visibilités pour les projets

Gitlab 6.4 de nouvelles options de visibilités pour les projets

Une grande majorité de développeurs utilisent un logiciel de gestion de version pour leurs projets. Surtout sur les gros projets afin de s’y retrouver parmi la multitude de fichiers sources créés, modifiés, détruits par l’ensemble de l’équipe de développement.

Parmi ses logiciels le plus répandut est Git. Pour faire simple Gitlab est en réalité une interface web s’appuyant sur les commandes de bases de Git, comme le fait le très populaire GitHub.

Certes je n’ai pas de gros projets de développements, je ne me considère pas comme un développeur, mais plutôt comme quelqu’un qui script. Je dois reconnaître qu’il est  très confortable de gérer  les différentes versions de mes scripts via une interface graphique.

Dès le  début j’avais pensé utiliser Github pour mes petits projets de script afin de pouvoir garder un historique de mes modifications et de mes « dotfiles ». Mais Github est une société privée qui ne permet pas de configurer la visibilité par défaut d’un projet à moins d’avoir un compte payant, en effet tout est public sur Github. Ce n’est pas le fait de payer qui me dérangeait dans l’offre de Github, mais qu’encore une fois il faillait confier ses données à un tier. J’ai  pris la décision de me configurer un serveur Gitlab le petit frère de Github.

Cette nouvelle version ajoute principalement des options dans la visibilité des projets développés. Avant la version 6.4 nous ne pouvions définir que deux modes de visibilité :

  1. Privé
  2. Public

Il était très gênant pour moi lorsque je voulais partager des scripts de configuration sensible de les mettre en mode public, car n’importe qui pouvait cloner mon dépôt. A chaque fois j’étais obligé de modifier mes scripts en effaçant les variables sensibles.

Avec 6.4 c’est fini le nouveau mode « internal Project », permet uniquement aux personnes possédant un compte sur notre Gitlab de pourvoir cloner le dépôt. Depuis cette mise à jour cela me simplifie beaucoup les choses, car je peux travailler avec mes collègues de confiance et nous pouvons partager, modifier, comparer, nos scripts de configuration.

Je n’ai rencontré qu’une petite difficulté lors de la mise à jour de 6.3 vers la 6.4, pendant le changement de branche :

 J’ai rectifié avec un :

Si vous voulez en savoir plus voici quelques liens utiles pour :

Bizarrement l’équipe de développement à choisi d’héberger le projet sur github et non sur leur propre plate-forme, peut-être pour éviter de s’attirer les foudres de son grand frère Github.

5 réactions au sujet de « Gitlab 6.4 de nouvelles options de visibilités pour les projets »

    1. Au contraire je vois plein inconvénients à héberger un prjet sut Github puisque se sont les sources de nos projets donc le cœur du projet même que l’on met entre les mains d’inconnus. Et qui plus est une société privé à but lucratif. Personnes nous ce qu’ils en font.

      De plus le tout public me gêne énormément pour les raisons invoquées dans mon billets. Le fait de forker le fork du fork quelle perte de temps pourquoi réinventé la roue plutôt que d’y participer ? Je n’ai pas les chiffres mais je suis sûr que plus de la moitié des projet sur Github son des fork eux même forkés.

      Bref tu as compris ton argumentaire ne m’a pas convaincu sur Github. Après l’avantage des logiciels libre c’est le choix et c’est encore la seule chose qui nous reste.

  1. En hébergeant des projets propriétaires sur github, je vois le problème de le confier à une société. Mais pour des projets libre je ne vois pas ce que cela change, au mieux les gens de github vont regarder ce que tu fais et peut-être s’y intéresser et donc faire avancer le projet.

    En revanche le fait de forker des forks etc me parret aussi imparfait. Comme tu dis cela peut devenir une perte de temps, mais en même temps le fait de mettre un logiciel sous licence libre est justement pour que l’on puisse faire cela. Le fork de github est peut-être trop facile à faire, et donc sur-utilisé. À moins que ce ne soit le fait d’entrer dans une communauté de dev d’un projet qui ne soit trop compliqué.

  2. GitHub collabore et soutient le libre, mais ne l’est pas. Le principe de brider l’utilisation dans certains cas et pas d’autre est ce qui a fait que le mouvement libre a dut être créé pour contrer ce genre de phénomène. Si le fait de faire un dépôt privé est interdit dans le cadre d’un modèle économique, cela pousse surtout github a devenir le point d’entrée pour télécharger la dernière version, à devenir incontournable

    Techniquement parlant on recentralise autour d’une infrastructure propriétaire, qui pourrait très bien décider de censurer un projet. Il faudrait alors refaire toute la documentation, communiquer sur le fait que le dépôt sur Github n’est plus le dépôt public officiel etc …

    Donc est-ce dangereux pour les données … certainement pas, c’est public et en cas de fermeture le côté décentralisé de GIT protège, par contre sur le plan de la communication on laisse une solution propriétaire être le porte drapeau du projet. Aujourd’hui des sociétés sont persuadés que pour utiliser git il faut payer une licence à github …

  3. Tu as raison sur ce point le côté décentralisé de Git sauve un peu la mise. Mais personnellement j’ai la compétence, l’infrastructure, et l’envie d’auto-héberger un dépôt git avec GitLab alors pourquoi ce priver ?

    Github n’est pas incontournable, c’est juste qu’ils ont su le devenir, tu as des alternatives comme plateforme git libre comme gitorius, qui est aussi facile et pratique à utiliser.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.