Сохранить рабочее пространство Дженкинса

Вы можете просто заархивировать все рабочее пространство в конце сборки. Затем он будет удален при удалении задания.

Сделать это:

• Добавить действие после сборки -> «Архивировать артефакты»
• Введите ** как «Файлы для архивации».

Если вы хотите настроить это для каждого запуска, вы можете создать параметр сборки:

• (включите «Это параметризованная сборка», если она еще не включена)
• добавьте параметр типа "Выбор параметра" и назовите его ARCHIVE
• с вариантами выбора <blank line> и ** (буквально поставьте пустую первую строку, затем вторая строка будет ровно **. Без кавычек)
• используйте ${ARCHIVE} как «Файлы для архивации» в «Дополнительной» настройке действия «Архивировать артефакты»
• включить флажок «Не завершать сборку, если архивация ничего не возвращает»

Вы можете определить агента в дырочном конвейере, поэтому jenkins будет использовать только каталог «рабочей области».

Например (это НЕ РАБОТАЕТ пример):

pipeline {
    agent any 
    environment {
        // Environment variables
    }    
    stages {
        stage('Clear dir') {
            steps {
                deleteDir()
            }
        }
        stage('Make checkout') {
            agent any    // **THIS IS WRONG!!!!** 
            steps {
                echo 'Making checkout'
            }
        }
    } 
}

В предыдущем примере «agent any» внутри сцены позволит jenkins создать папку «workspace@2».

Чтобы этого не произошло, оставляйте агент только в конвейере. Правильный пример:

pipeline {
    agent any   // This is right! leave only this mention of agent 
    environment {
        // Environment variables
    }    
    stages {
        stage('Clear dir') {
            steps {
                deleteDir()
            }
        }
        stage('Make checkout') {
            steps {
                echo 'Making checkout'
            }
        }
    } 
}

Дженкинс сохраняет текущую рабочую область как переменную среды ${WORKSPACE}. Вы можете переименовать его в любой момент задания, если вы также установите переименованный путь к абсолютному каталогу для переменной ${WORKSPACE} в сборке. Когда это сделать, теперь ваш выбор.

Другой вариант — запланировать подчиненное задание и передать ${WORKSPACE} этому заданию в качестве параметра, чтобы вы могли переименовать его.

Этот ответ приходит немного поздно и, вероятно, не совсем правильный ответ на ваш вопрос, но это первый билет, который я нашел при поиске решения моей проблемы.

У меня возникла проблема с наличием двух папок JobName_XXXX и JobName_XXXX@2. Сначала моя сборка работала хорошо, и я добавил параллельную сборку для другого узла Jenkins. После того, как я удалил параллельную сборку, у меня возникла проблема с build. Это больше не сработало. Я использовал конвейерный редактор blueocean для создания Jenkinsfile. Удалив параллельную сборку, я установил «агент: любой» для каждого шага. Это заставило Дженкинса сбросить scm внутри шага. Поэтому я не мог использовать результаты сборки предыдущих шагов, и сборка зависла. Решение состояло в том, чтобы удалить «агент: любой» из шагов/этапов. Можно иметь агента: любой; непосредственно внутри трубопровода. С редактором конвейера вы не можете удалить эти вещи типа «агент: любой» — по крайней мере, не сейчас? Поэтому отредактируйте Jenkinsfile вручную.