J'ai un pipeline qui s'exécute de cette façon:
Stage 1 -----> Stage 2 ----> Stage4
clone repo | exec email
| results
--> Stage 3
exec
Les étapes 1, 2 et 3 s'exécutent toutes à l'intérieur d'une image docker, toutes partageant un répertoire réseau pour les espaces de travail.
Mon problème est que lorsque l'étape 3 démarre, elle échoue car les fichiers clonés ne sont pas là. L'étape 3 a créé un nouvel espace de travail nommé MyJobName @ 2 et il est vide. Il semble que le problème survient uniquement lorsqu'il y a des étapes parallèles.
Comment dois-je le résoudre?
4 Réponses :
Vous pouvez regrouper plusieurs étapes en une seule étape. Ensuite, les étapes se partagent sur Workspace.
Si stage3 n'est là que pour envoyer les résultats par e-mail, vous devez utiliser des artefacts d'archive, puis envoyer les résultats par e-mail.
Plusieurs étapes en une seule étape peuvent-elles avoir une exécution parallèle?
Vous pouvez suivre les étapes de l'étape 4 dans les étapes 3 et 2
Vous pouvez définir l'espace de travail pour chaque étape séparément afin que, dans votre exemple, les étapes 2 et 4 partagent le même espace de travail. Pour l'étape 3, vous devrez définir un autre customWorkspace
Le code serait le suivant:
stage('Pipeline Test')
{
stage('Test')
{
agent
{
node
{
customWorkspace 'workspace/justATest'
}
}
steps
{
//everything is executed in the workspace declared above
}
J'utilise des pipelines déclaratifs, donc je n'ai pas l'option node . Comment le configurerais-je?
Êtes-vous sûr d'utiliser un pipeline déclaratif? Mon exemple de code peut être utilisé pour cela (Jenkinsfile) donc cela devrait fonctionner correctement.
Ne fonctionne pas, il n'a pas obéi à mon chemin configuré. J'ai essayé de définir: parallel {stage ('Hom') {agent {docker {image "$ {imageBuild}" args "$ {dockerArgs}" customWorkspace "/ var / jenkins_home / workspace / MyJobName"}}
Eh bien, voici ma réponse originale qui échoue toujours. Mon installation utilisait une ancienne version de docker et j'obtiens toujours l'erreur:
Docker version is older than 17.12, working directory will be /var/jenkins_home/workspace/ICP-bdm-Revisao not /var/jenkins_home/workspace/ICP-bdm-Revisao@2
Je pensais que le problème était résolu, mais quand j'ai commencé à utiliser des étapes plus parallèles, le problème est revenu.
J'ai essayé ces 3 solutions et elles ont échoué
Ma solution encore plus hacker était de changer chaque commande pour utiliser des chemins absolus ou en cd vers le répertoire avant d'exécuter chaque commande shell.
Ancienne réponse qui devrait fonctionner si vous avez un ancien docker:
Voici ma solution très hacky. Je n'ai pas pu empêcher Jenkins de créer un pipeline différent à chaque étape, donc ma solution était:
myWorkspace dir (myWorkspace) {...} J'ai rencontré un problème similaire. J'ai un Jenkinsfile où chaque étape s'exécute dans son propre conteneur et certaines étapes se déroulent en parallèle.
La principale différence est que j'utilise un pipeline déclaratif pour lequel l'espace de travail est plus ou moins défini après le clone git. Cela signifie que l'espace de travail MyJobName (de l'étape 2) et MyJobName @ 2 (de l'étape 3) contient le dépôt avec les derniers commits.
Cela résout déjà fondamentalement le problème que vous avez mentionné, mais j'avais besoin de plus.
À l'étape 4, j'avais besoin des résultats de l'étape 2 ET de l'étape 3. Mais à l'étape 4, seul l'espace de travail MyJobName est disponible, pas l'espace de travail MyJobName @ 2 .
/ p>
Pour cela, j'ai utilisé les les données de mise en cache pour les conteneurs < / a> astuce.
Je ne comprends pas. Comment la configuration d'une commande Docker comme celle-ci entraîne-t-elle la conservation des fichiers dans l'espace de travail?
@PatrickSzalapski l'argument Docker crée un volume. Ce volume vous donne un répertoire persistant en dehors du cycle de vie d'un conteneur (qui ne vit que pour une seule étape). Est-ce que cela est clair?