tag:linuxfr.org,2005:/tags/gitblit/publicLinuxFr.org : les contenus étiquetés avec « gitblit »2015-10-14T18:36:26+02:00/favicon.pngtag:linuxfr.org,2005:Post/359342015-10-13T15:02:53+02:002015-10-13T15:02:53+02:00Installer un service manuellement sur Synology sous Llinux - GitBlit<p>Bonjour le forum linuxfr</p>
<p>Je ne suis pas un pro sur Linux mais j'ai déjà installé quelques serveurs FTP, HTTP, Python, etc.</p>
<p>Mais maintenant je souhaiterai installer le serveur GitBlit sur mon NAS Synology.<br><a href="http://gitblit.com">http://gitblit.com</a> (An open source "GitHub like" server)</p>
<p>Sinologie utilise une distribution custom de Linux. </p>
<p>J'ai réussi sans mal à installer la version Ubuntu de GitBlit et ça marche super.<br>
Cependant je ne peux pas installer le service GitBlit car j'aimerai lancer le serveur au démarrage.</p>
<p>Mais je ne peux pas lancer le fichier <strong>install-service-ubunt.sh</strong> pvrcequ'il n'y a pas de fichier <strong>update.rc</strong> sur cette distib Linux.<br>
```</p>
<h2 id="binbash">!/bin/bash</h2>
<p>sudo cp service-ubuntu.sh /etc/init.d/gitblit<br>
sudo update-rc.d gitblit defaults<br>
```Donc j'aimerais installer ce service manuellement mais je ne sais pas comment faire sur Linux.</p>
<p>Cimer :)</p><div><a href="https://linuxfr.org/forums/linux-debutant/posts/installer-un-service-manuellement-sur-synology-sous-llinux-gitblit.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/107046/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debutant/posts/installer-un-service-manuellement-sur-synology-sous-llinux-gitblit#comments">ouvrir dans le navigateur</a>
</p>
badbenhttps://linuxfr.org/nodes/107046/comments.atomtag:linuxfr.org,2005:News/351912014-03-24T11:56:26+01:002014-03-26T13:19:28+01:00Sortie de Gitblit 1.4.xLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Gitblit est un outil de gestion de dépôt Git, à l’instar de Gitosis ou Gitolite. L’idée est de permettre de partager ses dépôts, gérer des droits d'accès, fournir des sauvegardes… tout en restant dans les murs de l’entreprise si nécessaire.</p>
<p>Pour les entreprises, justement, qui n’ont pas toujours de compétences Rails ou de culture des clefs SSH, Gitblit possède certains atouts. Au niveau administration, avec une application légère en Java, autonome ou hébergeable dans un Tomcat ou dans le Cloud. <br>
Au niveau de la gestion des utilisateurs, Gitblit offre, au choix, des solutions généralement appréciées des entreprises : LDAP ou Active directory avec gestion des habilitations basée sur les groupes, Windows, <a href="http://fr.wikipedia.org/wiki/Pluggable_Authentication_Modules">PAM</a>, Conteneur type Tomcat ou personnalisé. La gestion par clefs SSH sera apportée par la version 1.5.</p>
<p>Associé aux autres fonctionnalités plus courantes, Gitblit offre la possibilité de mettre en place un <em>Github-like</em> dans son entreprise.</p></div><ul><li>lien nᵒ 1 : <a title="http://www.gitblit.com/" hreflang="en" href="https://linuxfr.org/redirect/89801">Site officiel</a></li><li>lien nᵒ 2 : <a title="https://next-gitblit.rhcloud.com/" hreflang="en" href="https://linuxfr.org/redirect/89802">Demo de la prochaine version</a></li><li>lien nᵒ 3 : <a title="https://github.com/johannol/gitblit" hreflang="en" href="https://linuxfr.org/redirect/89837">Fork Github pour la traduction française</a></li><li>lien nᵒ 4 : <a title="http://vimeo.com/86164723" hreflang="en" href="https://linuxfr.org/redirect/89838">Screencast de fonctionnalités liées aux Tickets</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#fonctionnalit%C3%A9s-pr%C3%A9c%C3%A9dentes">Fonctionnalités précédentes</a><ul>
<li><a href="#gestion-des-hooks">Gestion des Hooks</a></li>
<li><a href="#f%C3%A9d%C3%A9ration-et-r%C3%A9plication">Fédération et réplication</a></li>
<li><a href="#divers">Divers</a></li>
</ul>
</li>
<li>
<a href="#nouveaut%C3%A9s-majeures-apport%C3%A9es-par-la-version-14x">Nouveautés majeures apportées par la version 1.4.x</a><ul>
<li><a href="#tickets">Tickets</a></li>
<li><a href="#workflow-de-collaboration-pull-request">Workflow de collaboration (pull-request)</a></li>
</ul>
</li>
<li><a href="#licence-et-contribution">Licence et Contribution</a></li>
</ul><h2 id="fonctionnalités-précédentes">Fonctionnalités précédentes</h2>
<h3 id="gestion-des-hooks">Gestion des Hooks</h3>
<p>Un mécanisme de <em>Hook</em> (ou <em>Trigger</em>) est accessible, permettant de scripter des actions lors d’un <em>push</em>. Ils se programment en Groovy et ont accès au cœur de l’application. Quelques lignes suffisent donc pour créer une interaction avec une intégration continue ou une gestion de ticket. Des exemples utilisables sont fournis, entre autres, avec Jenkins ou Redmine.</p>
<p>Un aspect intéressant, c’est qu’il est possible de définir des <em>Hooks</em> systématiquement exécutés (comme avec Subversion) pour une intégration avec Jenkins, mais également des <em>Hooks</em> activables à la demande et par projet dans l’interface. C’est le chef de projet qui choisit la gestion de tickets utilisée sur ce projet.</p>
<h3 id="fédération-et-réplication">Fédération et réplication</h3>
<p>Un système complet de fédération de serveurs est utilisable. Les objectifs possibles peuvent être, par exemple, d’avoir un miroir permanent sur un autre site afin de permettre une reprise d’activité rapide en cas d’incident (PRA).</p>
<p>Ou, autre cas d’entreprise pour les grosses structures, d’avoir un dépôt dans chaque site ou ville, consolidé au niveau national.</p>
<h3 id="divers">Divers</h3>
<p>Quelques autres fonctionnalités intéressantes :</p>
<ul>
<li>possibilité de n’être qu’un simple visionneur de dépôt d’un autre service Git, comme Gitolite avec SSH, ou Gerrit ;</li>
<li>une indexation Lucene pour faire des recherches performantes sur un ensemble de dépôts ;</li>
<li>des menus personnalisables pour les clients Git utilisables dans l’entreprise ;</li>
<li>une API JSON-RPC, qui sera d’ailleurs largement complétée avec la version 1.5, afin de permettre des <em>workflows</em> avancés, comme des acceptations partielles par Jenkins de <em>pull-request</em>. </li>
</ul><h2 id="nouveautés-majeures-apportées-par-la-version-14x">Nouveautés majeures apportées par la version 1.4.x</h2>
<h3 id="tickets">Tickets</h3>
<p>Une gestion de Tickets similaire à GitHub/BitBucket a été implémentée mais un peu différemment. Il n’y a pas de distinction entre un ticket et un <em>pull request</em>.</p>
<p>Chaque ticket peut avoir un ou plusieurs <em>commit(s)</em> lié(s) à une branche et il n’y a pas nécessité de créer plusieurs tickets pour différentes versions (<em>forks</em>) du même code.</p>
<p>Au niveau de Gitblit, la conception tourne autour de quelques principes :</p>
<ul>
<li>gestion simple pour tracer les actions ou les rapports d’utilisateurs ;</li>
<li>chaque ticket peut contenir des <em>commits</em> partagés par un contributeur ;</li>
<li>le ticket doit être la source canonique de <em>commits</em> lié au ticket (et non les <em>commits</em> d’un <em>fork</em>) ;</li>
<li>les contributeurs supplémentaires d’un problème doivent pouvoir développer des ensembles de <em>patches</em> pour un ticket, et non seulement le créateur du ticket. Le ticket rassemble donc l’ensemble des contributions et non seulement une revue de code ;</li>
<li>pas de perte d’historique entre le mainteneur ou contributeurs.</li>
</ul><p>Gitblit a pris son inspiration depuis GitHub, BitBucket, and Gerrit. Les différents mécanismes techniques sous‐jacents ont été implémentés et testés avant de faire les choix définitifs.</p>
<h3 id="workflow-de-collaboration-pull-request">Workflow de collaboration (pull-request)</h3>
<p>Les <em>pull requests</em> à la manière de GitHub demandent le <em>workflow</em> suivant :</p>
<ul>
<li>
<em>forker</em> le ProjetA en MonProjetA ;</li>
<li>cloner MonProjetA sur le poste de travail ;</li>
<li>créer MonProjetA_Clone:topic_branch et travailler sur la contribution ;</li>
<li>faire un <em>push</em> MonProjetA_Clone:topic_branch upstream vers <code>MonProjetA:topic_branch</code> ;</li>
<li>Ouvrir une <em>pull request</em> depuis MonProjetA:topic_branch vers <code>ProjetA:integration_branch</code> ;</li>
<li>Le propriétaire de ProjetA fait un <em>pull</em> <code>MonProjetA:topic_branch</code> vers <code>ProjetA:integration_branch</code> et inspecte la contribution ;</li>
<li>Le propriétaire de ProjetA fait enfin un <em>push</em> de la contribution fusionnée vers <code>ProjetA:integration_branch</code>.</li>
</ul><p>Le flux avec Gitblit ressemble à ceci :</p>
<ul>
<li>cloner ProjetA ;</li>
<li>créer <code>ProjetA_Clone:topic_branch</code> et travailler sur la contribution ;</li>
<li>faire un <em>push</em> <code>ProjetA_Clone:topic_branch upstream</code> vers <code>ProjetA:refs/for/[new|id]</code> ,</li>
<li>le propriétaire de ProjetA fait un <em>fetch</em> et un <em>merge</em> de la branche ticket/[id] ;</li>
<li>le propriétaire de ProjetA fait un <em>push</em> de la fusion vers <code>ProjetA:integration_branch</code>.</li>
</ul><p>Le workflow Gitblit supprime la conception à 4 dépôts de Github (canonique, copie de travail canonique, fork, & copie de travail du fork) au profit d'une à 3 dépôts (canonique, copie de travail canonique, copie de travail du clone). </p>
<p>La conséquence de l’implémentation de Gitblit, c’est que pour le travail d’une nouvelle fonctionnalité donnée, il y a harmonie entre un ticket, les <em>commits</em> dans une branche liée, la contribution à plusieurs sur cette branche, les revues de code (avec notes) et la fusion.</p>
<p>Au passage, on économise les ressources système d’un dépôt supplémentaire et d’une étape dans l’interface Web.</p>
<h2 id="licence-et-contribution">Licence et Contribution</h2>
<p>Gitblit est sous licence Apache 2.0 et est développé pour l’instant sur Github. Les contributions sont appréciées, via le mécanisme du <em>fork</em> et <em>pull-request</em>.</p>
<p>Une traduction en français de l’interface est commencée sur le <em>fork</em> listé dans les liens, n’hésitez pas à y contribuer. L’objectif premier est d’avoir une traduction gardant le nom des commandes Git intact et, peut‐être ensuite, une autre plus « québécoise » traduisant intégralement tous les termes. Les gens choisiront.</p></div><div><a href="https://linuxfr.org/news/sortie-de-gitblit-1-4-x.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/101618/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/sortie-de-gitblit-1-4-x#comments">ouvrir dans le navigateur</a>
</p>
Johann Ollivier-LapeyreDavy DefaudBAudpalm123olivierwebclaudexNeoXhttps://linuxfr.org/nodes/101618/comments.atom