J'ai un gros dépôt git et un pipeline multibranch. J'ai commencé à utiliser un référentiel de référence git dans Jenkins. (Création d'un dossier et application de git clone --mirror git@github.com: my-user / my-repository.git )
Dans les journaux de construction, il est dit "Utilisation du référentiel de référence". Mais je n'ai ressenti aucune amélioration de la vitesse. Dois-je apporter des modifications au code de mon pipeline Jenkins? / / >
3 Réponses :
Ces commandes utilisent-elles le référentiel de référence ou non?
Non pour git reset ou git checkout : ces commandes locales qui utilisent le référentiel cloné localement , pas la télécommande.
Oui pour git fetch --tags origin . pour être sûr, ajoutez une étape avec un git remote -v , pour confirmer que origin est bien git@github.com: my-user / my-repository. git
Veuillez consulter ce ticket: https://issues.jenkins-ci.org/ parcourir / JENKINS-54612
Il semble que lors de l'utilisation de Pipelines, le référentiel de référence soit ignoré. Je vois le même comportement, et il semble donc que la raison pour laquelle vous ne voyez aucune accélération est qu'il n'y a aucune accélération d'aucune sorte.
Si vous regardez les journaux Jenkins, vous verrez que les commandes git exécutées n'incluent pas de clone. Il fait git init, suivi de l'ajout de la télécommande, puis de la récupération. Il ne clone pas avec --reference, et il ne configure pas les informations / alternatives à la main. En conséquence, il va toujours faire un clonage complet depuis la télécommande.
Une solution de contournement potentielle serait d'ajouter une seconde télécommande, spécifiée avant la vraie télécommande. Au lieu d'une URL, utilisez le chemin local du référentiel de référence. Cela fonctionne pour moi directement avec la ligne de commande git. Il a expiré lorsque je l'ai essayé avec Jenkins. Cependant, cela peut être une idiosyncrasie de l'esclave avec lequel je teste, et cela vaut peut-être la peine de l'essayer par vous-même. Si cela fonctionne, assurez-vous d'utiliser des espaces de travail transitoires pour garder l'utilisation de l'espace sous contrôle, car il s'agit de copier plutôt que de référencer, mais ce sera toujours beaucoup plus rapide que de télécharger le référentiel entier.
Le bogue concerne uniquement Windows. Bien que je ne puisse rien dire sur cet environnement, nous avons une accélération significative sous Linux lors de l'utilisation du référentiel de référence.
@MaratC Le bogue n'est pas uniquement Windows; le titre est un abus de langage, et vous verrez également des personnes souffrant du problème sur Ubuntu si vous lisez le dernier commentaire sur ce ticket. Comme je l'ai décrit ci-dessus, le problème est lié à la séquence d'opérations effectuée par le plugin Git SCM, qui ne prévoit pas l'utilisation d'un référentiel de référence, ce qui rend l'option de configuration du référentiel de référence inutile. Cela affecte toutes les plates-formes.
nous avons commencé à utiliser le référentiel de référence dans notre configuration Jenkins, et cela a apporté des améliorations de vitesse extrêmement significatives pour l'étape git clone . Cela ne fonctionnerait pas si "aucune disposition pour l'utilisation d'un référentiel de référence" n'était faite.
Souhaitez-vous partager les commandes exactes exécutées par Jenkins pour y parvenir? Notez que le bogue semble spécifique aux pipelines. Il n'utilise pas "git clone", c'est pourquoi c'est un problème en premier lieu.
Mon pipeline a checkout scm , c'est le seul pertinent. Nous effaçons l'espace de travail à chaque exécution et clonons avec référence (cela prend ~ 20sec). Pour nous, cela fonctionne mieux que d'avoir un espace de travail persistant. Veuillez noter que la description originale du ticket a "[référence] semble fonctionner sur tous les agents que nous avons à l'exception de nos nœuds Windows" et "Je peux utiliser une étape sh pour cloner en utilisant le repo ref avec succès", donc le repo de référence fonctionne sûrement au moins pour certains scénarios.
D'après notre expérience:
Le référentiel de référence fonctionne pour git clone . Cette étape est passée de plus de 30 minutes à moins d'une minute dans notre environnement. Cela dit essentiellement "si j'ai besoin d'apporter un gros blob depuis git mais qu'il est déjà dans le miroir, gagnons du temps et apportons-le du miroir".
Le miroir doit être mis à jour assez fréquemment. Nous avons un travail qui le fait 3 à 4 fois par jour.
git checkout a besoin des données du miroir et du dépôt distant, car le miroir ne peut pas être compté de manière fiable pour être mis à jour. Les dernières modifications proviennent de la télécommande.
Quelque peu contre-intuitives, les opérations sont plus rapides lorsque vous n'utilisez aucun raccourci pour accélérer les opérations. Plus précisément, limiter --depth ralentit les choses lors de l'utilisation du miroir.
Si un dépôt a déjà été cloné sans miroir, il n'utilisera jamais le miroir. Vous souhaiterez peut-être effacer le dépôt et le recréer à l'aide du miroir.
Enfin, vous pouvez vérifier les améliorations de vitesse (le cas échéant) sur l'esclave Jenkins avec la commande suivante:
mkdir -p tmp && git clone git@github.com:my_org/my_repo.git tmp --reference /path/to/reference/my_repo.git/