Utiliser Hudson et construire des étapes avec plusieurs référentiels git

Question

J'essaie d'utiliser Hudson pour remplacer notre configuration actuelle de Buildbot. J'ai installé le plugin git. Notre configuration actuelle est comme:

ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git

Maintenant, pour construire project_a , j'ai ajouté un nouveau travail avec plusieurs référentiels git (ceux ci-dessus). Je voulais que Hudson clone les référentiels dans différents répertoires sous $ WORKSPACE , car test_framework a besoin de cette hiérarchie. Mais Hudson semble tout fusionner dans $ WORKSPACE . À partir du journal de la console:

warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0

Puis-je configurer cela dans Hudson pour qu'il s'adapte mieux à la configuration de notre projet? Dois-je créer un référentiel git factice local avec chaque projet sous forme de sous-modules git ou quelque chose d'autre?

Answer 1

Dans Hudson, vous pouvez chaîner plusieurs tâches ensemble. Vous pouvez essayer de créer des travaux Hudson distincts pour test_framework et un autre pour project_a. Hudson crée un répertoire distinct dans $ WORKSPACE pour chaque travail. Vous devez donc disposer de deux répertoires différents sous $ WORKSPACE.

Chaînage de la configuration

Dans la configuration du travail de project_a, faites défiler jusqu'à Actions de post-génération et cochez Créer d'autres projets ... Entrez test_framework en tant que projet à construire.

Dans la configuration du travail de test_framework, assurez-vous que Poll SCM est décoché et que l'option Construire après d'autres projets est définie sur projet_a.

Comment ça marche

Ce que vous avez maintenant configuré, c'est project_a interrogera le GDS à la recherche de modifications, puis les extraira de git. Exécutez les étapes de construction (le cas échéant) et, à la fin, déclenche le travail test_framework afin d'extraire les modifications de git (le cas échéant) et d'exécuter ses étapes de construction.

Answer 2

Le problème avec l'option "Construire d'autres projets". La solution est que si des modifications sont apportées à test_framework, cela ne déclenchera pas la construction de project_a. Au lieu de cela, je recommande d'abandonner le plug-in git et de configurer un " Execute shell " étape de construction avec les éléments suivants:

rm -rf ${WORKSPACE}/*

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

Créez ensuite des fichiers de raccordement "server: /repo/test_framework.git/hooks/post-receive" et " server: /repo/project_a.git/hooks/post-receive" avec le contenu suivant:

#!/bin/sh
curl http://hudson/job/job_name/build

Désormais, chaque fois que des modifications sont placées dans l'un des référentiels, le raccord utilise l'API de Hudson pour déclencher une construction.

Answer 3

Je me rends compte que cette question est très ancienne, mais j’ai rencontré le même problème et j’ai utilisé cette page pour préciser ma propre solution qui semble fonctionner très bien (même si elle est un peu compliquée). La majeure partie du crédit de cette solution devrait aller à Clinton (la seule raison pour laquelle je me donne la peine de soumettre cette réponse est que sa réponse ne semble pas adresser plusieurs référentiels qui doivent se trouver dans le même répertoire de base).

Supposons que vous ayez deux référentiels (A et B).

Étapes:

1) Créez deux projets pour extraire le code des référentiels distants A et B. Placez toutes les étapes de construction nécessaires dans l'un ou l'autre des référentiels.

2) Créez un troisième répertoire sans aucune gestion de contrôle de source. Ajoutez une étape de construction à ce projet pour exécuter une commande shell similaire à ceci:

ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B

(Vos chemins ne sont peut-être pas les mêmes. Recherchez-les vous-même!)

Vous pouvez maintenant ajouter toute autre étape de construction qui dépend de ce que A et B sont des soeurs dans un répertoire. Yay des liens symboliques!

3) Enchaînez les trois tâches. L'ordre des tâches d'extraction peut être important ou non (vous le savez mieux que moi), mais la tâche sans contrôle de source doit être le dernier maillon de la chaîne.

Answer 4

J'ai rencontré le même problème et le résous actuellement en créant un travail pour chaque projet et en utilisant le Copier le plug-in d'artefact pour permettre de créer le travail dépendant même si une mise à jour de Git est effectuée sur ses dépendances (afin d'éviter de créer au milieu d'une mise à jour du projet dont nous dépendons). .

Ainsi, project_a copiera les derniers artefacts stables dont il a besoin de test_framework et une mise à jour de la structure de test déclenchera la construction de project_a. project_a peut toujours être déclenché par une modification de Git, il ne fait que copier à nouveau les derniers artefacts de test_framework.

Answer 5

Le problème que vous décrivez est déjà classé comme un bogue dans le gestionnaire de bogues Jenkins: https: / /issues.jenkins-ci.org/browse/JENKINS-8082

Nous utilisons l'espace de travail personnalisé """ Option dans la configuration du travail de projet étendu pour extraire le référentiel de notre travail dans un sous-répertoire d'un autre travail.

Cet autre travail extrait le répertoire principal avec tous les sous-modules:

var/lib/jenkins/jobs/
  + main_job
    + workspace (main git checkout with submodules)
      + modules
        + mod1
        + mod2
  + mod1_job (custom workspace set to main_job/workspace/modules/mod1)
    + workspace (empty)