Задача Jenkins Pipeline не может найти script из-за создания пути @tmp

Я пишу задание на конвейер, которое вызывает другой script для выполнения. Файлы Jenkins и script существуют в одном каталоге, но в задании не удается найти script.

Это соответствующий бит script;

stage ('Update') {
    try {
        dir('jenkins/pipeline/update-jenkins-plugins-ppln') {
            sh 'ls -l'
            sh 'update-plugins.sh'
        }
}

который возвращает следующую ошибку:

[update-jenkins-plugins-ppln] Running shell script
+ ls -l
total 8
-rw-r--r-- 1 jenkins jenkins 2441 Dec 20 09:34 Jenkinsfile
-rwxr-xr-x 1 jenkins jenkins  506 Dec 19 14:06 update-plugins.sh
[Pipeline] sh
[update-jenkins-plugins-ppln] Running shell script
+ update-plugins.sh
/var/lib/jenkins/workspace/update-jenkins-plugins-ppln/jenkins/pipeline/[email protected]/durable-11cefdd0/script.sh: 2: /var/lib/jenkins/workspace/update-jenkins-plugins-ppln/jenkins/pipeline/[email protected]/durable-11cefdd0/script.sh: update-plugins.sh: not found

Как вы можете видеть, путь, который я использую, является правильным, потому что в соответствии с ls файл, который мне нужен update-plugins.sh, находится в каталоге, к которому я привязался. По какой-то причине, хотя при поиске script Дженкинса добавляется @tmp/durable-8d48734f/script.sh на путь.

Различные способы устранения неполадок:

  • Я прочитал, что вам нужно снова проверить ветку, даже если вы уже проверяете ее, чтобы получить файл Jenkins, так что я.
  • У меня есть ssh'd в поле Jenkins, чтобы проверить и да, script есть.

Почему Дженкинс добавляет бит @tmp, и есть ли способ предотвратить это поведение?

ОТВЕТЫ

Ответ 1

Пробовали ли вы использовать переменную среды рабочего пространства jenkins WORKSPACE (абсолютный путь рабочей области)? При этом ваша строка будет выглядеть примерно так:

sh '${WORKSPACE}/jenkins/pipeline/update-jenkins-plugins-ppln/update-plugins.sh'

Ответ 2

Я думаю, ваш pwd не находится в PATH, поэтому вы должны называть его следующим образом: sh './update-plugins.sh'

Ответ 3

У меня была такая же проблема. Я думаю, что @Oren технически ответил на ваш вопрос о том, почему Дженкинс создает это пространство tmp, но я могу поделиться некоторой информацией о том, как я решил это.

По сути, мой хост Jenkins содержит ссылки bin/sh на dash; не bash. Таким образом, использование POSIX-совместимого сценария оболочки решило эту проблему для меня.

Например, я пытался использовать shopt -s extglob для сопоставления с образцом:

stage {
    def shellCommand = $/ "rm -rf ! (_data|_includes|_plugins|Gemfile|_config.yml|page-builder)"/$
    sh(returnStdout: true, script: shellCommand).trim()
}

Поскольку dash не поддерживает extglob, extglob замена POSIX-совместимой команды find:

stage {
    sh('find . -regextype posix-extended -not -regex ".*includes.*|.*data.*|.*plugins.*|.*config.yml|.*Gemfile.*"')
}

Ответ 4

Папка @tmp предназначена для статистики работы Дженкинса и этапов (продолжительность этапов и т.д.), Вы можете удалить ее, если хотите быть в этом уверены. Я предполагаю, что ваша проблема связана с неверным путем, дважды проверьте ее.

Ответ 5

Я предполагаю, что этот конкретный случай не имеет ничего общего с конвейерами Jenkins, поскольку его можно воспроизвести за пределами Jenkins в консоли. Однажды я получил эту проблему из -за окончания строки DOS в моем скрипте, который я запустил в конвейере "sh()". Посмотрите на этот пример:

$ cat -v dos_formatted.sh
#! /bin/sh^M
pwd^M

$ cat script.sh
./dos_formatted.sh

$ sh -xe script.sh
+ ./dos_formatted.sh
script.sh: 1: script.sh: ./dos_formatted.sh: not found

Это хорошо иллюстрирует, что сообщение "not found" вводит в заблуждение. Сценарий находится в нужном месте, и разрешения достаточно, но при запуске его из другого сценария происходит сбой с таким сообщением об ошибке.

Код плагина Durable Task (https://github.com/jenkinsci/durable-task-plugin/blob/master/src/main/java/org/jenkinsci/plugins/durabletask/BourneShellScript.java) показывает, что плагин запускает автоматически сгенерированный script.sh как "sh -xe...", поэтому это точно наш случай.

Описанная выше ситуация может возникнуть, если вы "git clone" в каком-то (возможно, стороннем) проекте Git и не уверены, что он был клонирован с LF в стиле Unix.