Réponses:
Vous pouvez utiliser deleteDir()
comme dernière étape du pipeline Jenkinsfile (en supposant que vous n'ayez pas changé le répertoire de travail).
checkout scm
.
Comme @gotgenes l'a souligné avec Jenkins Version. 2.74 , le ci-dessous fonctionne, je ne sais pas depuis quand, peut-être si quelqu'un peut éditer et ajouter la version ci-dessus
cleanWs()
Avec, Jenkins Version 2.16 et le plugin Workspace Cleanup que j'ai, j'utilise
step([$class: 'WsCleanup'])
pour supprimer l'espace de travail.
Vous pouvez le visualiser en accédant à
JENKINS_URL/job/<any Pipeline project>/pipeline-syntax
Puis en sélectionnant "étape: Étape de construction générale" à partir de l'étape Exemple, puis en sélectionnant "Supprimer l'espace de travail une fois la construction terminée" dans l'étape de construction
Les solutions mentionnées deleteDir()
et cleanWs()
(si vous utilisez le plugin de nettoyage de l' espace de travail ) fonctionnent toutes les deux, mais la recommandation de l'utiliser dans une étape de construction supplémentaire n'est généralement pas la solution souhaitée . Si la génération échoue et que le pipeline est abandonné, cette étape de nettoyage n'est jamais atteinte et, par conséquent, l'espace de travail n'est pas nettoyé sur les générations ayant échoué.
=> Dans la plupart des cas, vous devriez probablement le mettre dans une condition post-built-step comme always
:
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
cleanWs()
}
}
}
cleanWs()
tant qu'étape les supprime avant l'exécution de la commande d'archivage post build. cleanWs()
devrait probablement toujours être exécuté en tant que commande post build
post
section, cleanWs()
peut être mis en sécurité en toute sécurité always
, mais l'endroit le plus sûr est à l'intérieur de la cleanup
condition:post { cleanup { cleanWs() } }
En fait, la fonction deleteDir supprime récursivement le répertoire courant et son contenu. Les liens symboliques et les jonctions ne seront pas suivis mais seront supprimés.
Pour supprimer un répertoire spécifique d'un espace de travail, encapsulez l'étape deleteDir dans une étape dir.
dir('directoryToDelete') {
deleteDir()
}
J'ai utilisé deleteDir () comme suit:
post {
always {
deleteDir() /* clean up our workspace */
}
}
Cependant, j'ai dû également exécuter un succès ou un échec APRÈS toujours mais vous ne pouvez pas commander les conditions de publication. L'ordre actuel est toujours, modifié, annulé, échoué, réussi puis instable.
Cependant, il existe une post-condition très utile, le nettoyage qui s'exécute toujours en dernier, voir https://jenkins.io/doc/book/pipeline/syntax/
Donc, à la fin, mon message était le suivant:
post {
always {
}
success{
}
failure {
}
cleanup{
deleteDir()
}
}
J'espère que cela peut être utile pour certains cas de coin
À l'aide du script de pipeline suivant:
pipeline {
agent { label "master" }
options { skipDefaultCheckout() }
stages {
stage('CleanWorkspace') {
steps {
cleanWs()
}
}
}
}
Suivez ces étapes:
options { skipDefaultCheckout() }
pour une exécution un peu plus rapide.
Si vous avez utilisé un espace de travail personnalisé dans Jenkins, deleteDir () ne supprimera pas le dossier @tmp.
Donc, pour supprimer @tmp avec l'espace de travail, utilisez ce qui suit
pipeline {
agent {
node {
customWorkspace "/home/jenkins/jenkins_workspace/${JOB_NAME}_${BUILD_NUMBER}"
}
}
post {
cleanup {
/* clean up our workspace */
deleteDir()
/* clean up tmp directory */
dir("${workspace}@tmp") {
deleteDir()
}
/* clean up script directory */
dir("${workspace}@script") {
deleteDir()
}
}
}
}
Cet extrait fonctionnera également pour l'espace de travail par défaut.
Nous nous assurons de travailler avec un espace de travail propre en utilisant une fonctionnalité du plugin git. Vous pouvez ajouter des comportements supplémentaires tels que «Nettoyer avant de passer à la caisse». Nous l'utilisons également pour «Prune obsolètes des branches de suivi à distance».
L'utilisation de l'extension 'WipeWorkspace' semble également fonctionner. Il nécessite la forme la plus longue:
checkout([
$class: 'GitSCM',
branches: scm.branches,
extensions: scm.extensions + [[$class: 'WipeWorkspace']],
userRemoteConfigs: scm.userRemoteConfigs
])
Plus de détails ici: https://support.cloudbees.com/hc/en-us/articles/226122247-How-to-Customize-Checkout-for-Pipeline-Multibranch-
Extensions GitSCM disponibles ici: https://github.com/jenkinsci/git-plugin/tree/master/src/main/java/hudson/plugins/git/extensions/impl
Nettoyage : étant donné que la section de publication d'un pipeline est garantie de s'exécuter à la fin de l'exécution d'un pipeline, nous pouvons ajouter une notification ou d'autres étapes pour effectuer la finalisation, la notification ou d'autres tâches de fin de pipeline.
pipeline {
agent any
stages {
stage('No-op') {
steps {
sh 'ls'
}
}
}
post {
cleanup {
echo 'One way or another, I have finished'
deleteDir() /* clean up our workspace */
}
}
}
Dans mon cas, je souhaite effacer les anciens fichiers au début de la construction, mais cela pose problème car le code source a été extrait.
Ma solution est de demander à git de nettoyer tous les fichiers (de la dernière compilation) dont il ne connaît pas l'existence:
sh "git clean -x -f"
De cette façon, je peux démarrer la compilation proprement, et si elle échoue, l'espace de travail n'est pas nettoyé et donc facilement débuggable.
Actuellement, deleteir () et cleanWs () ne fonctionnent pas correctement lors de l'utilisation du plugin Jenkins kubernetes, l'espace de travail du pod est supprimé mais l'espace de travail maître persiste
cela ne devrait pas être un problème pour les branches persistantes, lorsque vous avez une étape pour nettoyer l'espace de travail avant l'arnaque à la caisse. Il réutilisera fondamentalement le même espace de travail encore et encore: mais lors de l'utilisation de pipelines multibranch, le maître conserve tout l'espace de travail et le répertoire git
Je crois que cela devrait être un problème avec Jenkins, des lumières ici?