Рабочая область Jenkins Pipeline Wipe Out

Мы используем Jenkins 2.x и любим новый плагин Pipeline. Однако при таком большом количестве веток в репозитории дисковое пространство быстро заполняется.

Есть ли какой-либо плагин, совместимый с Pipeline, которым я могу стереть рабочее пространство при успешной сборке?

Вы можете использовать deleteDir()Jenkinsfile в качестве последнего шага конвейера (при условии, что вы не меняли рабочий каталог).

Как @gotgenes указал с версией Дженкинса. 2.74 , ниже работает, не уверен, с каких пор, может быть, кто-нибудь сможет отредактировать и добавить версию выше

cleanWs()

С Jenkins версии 2.16 и плагином очистки рабочей области , который у меня есть, я использую

step([$class: 'WsCleanup'])

чтобы удалить рабочую область.

Вы можете просмотреть его, перейдя в

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

Затем выберите «шаг: общий этап сборки» на этапе «Образец», а затем выберите «Удалить рабочую область после завершения сборки» на этапе сборки.

Упомянутые решения deleteDir()и cleanWs()(при использовании плагина очистки рабочей области ) работают, но рекомендация использовать его на дополнительном этапе сборки обычно не является желаемым решением . Если сборка завершается неудачно и конвейер прерывается, эта стадия очистки никогда не достигается, и поэтому рабочая область не очищается при неудачных сборках.

=> В большинстве случаев вам, вероятно, следует поместить его в состояние после создания шага, например always:

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

Фактически функция deleteDir рекурсивно удаляет текущий каталог и его содержимое. Символические ссылки и переходы не будут использоваться, но будут удалены.

Чтобы удалить определенный каталог рабочей области, оберните шаг deleteDir в шаг dir.

dir('directoryToDelete') {
    deleteDir()
}

Я использовал deleteDir () следующим образом:

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

Однако затем мне пришлось всегда запускать Успех или Неудачу ПОСЛЕ, но вы не можете заказать условия публикации. Текущий порядок всегда меняется, прерывается, сбой, успех, а затем нестабилен.

Однако есть очень полезное условие публикации: очистка всегда выполняется последней, см. Https://jenkins.io/doc/book/pipeline/syntax/

В итоге мой пост был таким:

post {
    always {

    }
    success{

    }
    failure {

    }
    cleanup{
        deleteDir()
    }
}

Надеюсь, это может быть полезно в некоторых случаях.

Используя следующий сценарий конвейера:

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

Следуй этим шагам:

1. Перейдите к последней сборке задания конвейера, от которого вы хотите очистить рабочее пространство.
2. Щелкните ссылку Воспроизведение в меню LHS.
3. Вставьте указанный выше сценарий в текстовое поле и нажмите «Выполнить».

Если вы использовали настраиваемое рабочее пространство в Jenkins, то deleteDir () не удалит папку @tmp.

Итак, чтобы удалить @tmp вместе с рабочей областью, используйте следующие

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

Этот фрагмент также будет работать для рабочей области по умолчанию.

Мы гарантируем, что работаем с чистой рабочей средой, используя функцию плагина git. Вы можете добавить дополнительные варианты поведения, например «Очистить перед оформлением заказа». Мы также используем это для «Удаление устаревших ветвей удаленного отслеживания».

Расширение WipeWorkspace тоже работает. Требуется более длинная форма:

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

Подробнее здесь: https://support.cloudbees.com/hc/en-us/articles/226122247-How-to-Customize-Checkout-for-Pipeline-Multibranch-

Доступные расширения GitSCM здесь: https://github.com/jenkinsci/git-plugin/tree/master/src/main/java/hudson/plugins/git/extensions/impl

Для Jenkins 2.190.1 это точно работает:

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

Очистка : поскольку пост-раздел конвейера гарантированно запускается в конце выполнения конвейера, мы можем добавить некоторые уведомления или другие шаги для выполнения финализации, уведомления или других задач конца конвейера.

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

В моем случае я хочу удалить старые файлы в начале сборки, но это проблематично, поскольку исходный код был проверен.

Мое решение - попросить git очистить все файлы (из последней сборки), о которых он не знает:

    sh "git clean -x -f"

Таким образом, я могу начать сборку с нуля, и в случае сбоя рабочая область не будет очищена и, следовательно, легко поддается отладке.

В настоящее время и deletedir (), и cleanWs () не работают должным образом при использовании плагина Jenkins kubernetes, рабочая область пода удаляется, но основная рабочая область сохраняется.

это не должно быть проблемой для постоянных веток, когда у вас есть шаг по очистке рабочего пространства перед мошенничеством с оформлением заказа. Он будет в основном повторно использовать одно и то же рабочее пространство снова и снова: но при использовании многоотраслевых конвейеров мастер сохраняет всю рабочую область и каталог git

Я считаю, что это должно быть проблемой с Дженкинсом, есть ли здесь просветление?