Jenkins Pipeline Wipe Out Workspace

Używamy Jenkinsa 2.xi uwielbiamy nową wtyczkę Pipeline. Jednak przy tak dużej liczbie gałęzi w repozytorium miejsce na dysku szybko się zapełnia.

Czy jest jakaś wtyczka zgodna z Pipeline, którą mogę wyczyścić obszar roboczy po udanej kompilacji?

Możesz użyć deleteDir()Jenkinsfile jako ostatniego kroku potoku (zakładając, że nie zmieniłeś katalogu roboczego).

Jak @gotgenes wskazał w wersji Jenkins. 2.74 , poniżej działa, nie jestem pewien od kiedy, może jeśli ktoś może edytować i dodać powyższą wersję

cleanWs()

Dzięki, Jenkins Wersja 2.16 i Oczyszczanie Workspace Plugin , że mam, używam

step([$class: 'WsCleanup'])

aby usunąć obszar roboczy.

Możesz go wyświetlić, przechodząc do

JENKINS_URL/job/<any Pipeline project>/pipeline-syntax

Następnie wybierz „krok: Ogólny krok kompilacji” z kroku Przykład, a następnie wybierz „Usuń obszar roboczy po zakończeniu kompilacji” z kroku kompilacji

Wymienione rozwiązania deleteDir()i cleanWs()(jeśli używasz wtyczki do czyszczenia obszaru roboczego ) działają, ale zalecenie użycia go w dodatkowym etapie kompilacji zwykle nie jest pożądanym rozwiązaniem . Jeśli kompilacja się nie powiedzie, a potok zostanie przerwany, ten etap czyszczenia nigdy nie zostanie osiągnięty, a zatem obszar roboczy nie jest czyszczony w przypadku nieudanych kompilacji.

=> W większości przypadków prawdopodobnie powinieneś umieścić go w stanie po zbudowaniu kroku, takim jak always:

pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
                echo 'Hello World'
            }
        }
    }
    post { 
        always { 
            cleanWs()
        }
    }
}

W rzeczywistości funkcja deleteDir rekurencyjnie usuwa bieżący katalog i jego zawartość. Symboliczne łącza i skrzyżowania nie będą śledzone, ale zostaną usunięte.

Aby usunąć określony katalog obszaru roboczego, zawiń krok deleteDir do kroku dir.

dir('directoryToDelete') {
    deleteDir()
}

Użyłem deleteDir () w następujący sposób:

  post {
        always {
            deleteDir() /* clean up our workspace */
        }
    }

Jednak musiałem wtedy również uruchamiać Sukces lub Niepowodzenie PO zawsze, ale nie możesz zamówić warunków wysyłki. Bieżąca kolejność jest zawsze zmieniona, przerwana, niepowodzenie, sukces, a następnie niestabilna.

Istnieje jednak bardzo przydatny warunek postu, czyszczenie, które zawsze działa jako ostatnie, zobacz https://jenkins.io/doc/book/pipeline/syntax/

Ostatecznie mój post wyglądał następująco:

post {
    always {

    }
    success{

    }
    failure {

    }
    cleanup{
        deleteDir()
    }
}

Miejmy nadzieję, że może to być pomocne w niektórych przypadkach narożnych

Przy użyciu następującego skryptu potoku:

pipeline {
    agent { label "master" }
    options { skipDefaultCheckout() }
    stages {
        stage('CleanWorkspace') {
            steps {
                cleanWs()
            }
        }
    }
}

Wykonaj następujące kroki:

1. Przejdź do najnowszej kompilacji zadania potoku, z którego chcesz wyczyścić obszar roboczy.
2. Kliknij łącze Odtwórz w menu LHS.
3. Wklej powyższy skrypt w polu tekstowym i kliknij Uruchom

Jeśli użyłeś niestandardowego obszaru roboczego w Jenkins, funkcja deleteDir () nie usunie folderu @tmp.

Aby usunąć @tmp wraz z użyciem obszaru roboczego, wykonaj następujące czynności

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()
            }
        }
    }
}

Ten fragment będzie działał również dla domyślnego obszaru roboczego.

Upewniamy się, że pracujemy z czystym obszarem roboczym, korzystając z funkcji wtyczki git. Możesz dodać dodatkowe zachowania, takie jak „Wyczyść przed zakupem”. Używamy tego również do „Przycinania starych gałęzi zdalnego śledzenia”.

Wydaje się, że działa również rozszerzenie „WipeWorkspace”. Wymaga dłuższej formy:

checkout([
   $class: 'GitSCM',
   branches: scm.branches,
   extensions: scm.extensions + [[$class: 'WipeWorkspace']],
   userRemoteConfigs: scm.userRemoteConfigs
])

Więcej szczegółów tutaj: https://support.cloudbees.com/hc/en-us/articles/226122247-How-to-Customize-Checkout-for-Pipeline-Multibranch-

Dostępne rozszerzenia GitSCM tutaj: https://github.com/jenkinsci/git-plugin/tree/master/src/main/java/hudson/plugins/git/extensions/impl

W przypadku Jenkins 2.190.1 to na pewno działa:

    post {
        always {
            cleanWs deleteDirs: true, notFailBuild: true
        }
    }

Oczyszczanie : Ponieważ sekcja postu potoku ma gwarancję uruchomienia pod koniec wykonywania potoku, możemy dodać pewne powiadomienia lub inne kroki w celu wykonania finalizacji, powiadomienia lub innych zadań końca potoku.

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 */
        }
    }
}

W moim przypadku chcę wyczyścić stare pliki na początku kompilacji, ale jest to problematyczne, ponieważ kod źródłowy został pobrany.

Moim rozwiązaniem jest poproszenie gita o wyczyszczenie wszystkich plików (z ostatniej kompilacji), o których nie wie:

    sh "git clean -x -f"

W ten sposób mogę rozpocząć kompilację w sposób czysty, a jeśli się nie powiedzie, obszar roboczy nie zostanie wyczyszczony, a zatem można go łatwo debugować.

Obecnie zarówno deleteir (), jak i cleanWs () nie działają poprawnie podczas korzystania z wtyczki Jenkins kubernetes, obszar roboczy pod jest usuwany, ale główny obszar roboczy pozostaje

nie powinno to stanowić problemu dla trwałych oddziałów, gdy masz krok do wyczyszczenia obszaru roboczego przed oszustwem przy kasie. Zasadniczo będzie ponownie używać tego samego obszaru roboczego: ale podczas korzystania z potoków wielobranżowych master zachowuje cały obszar roboczy i katalog git

Uważam, że to powinien być problem z Jenkinsem, jakieś oświecenie tutaj?