Я пишу задание на конвейер, которое вызывает другой 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 на путь.
Различные способы устранения неполадок:
Почему Дженкинс добавляет бит @tmp, и есть ли способ предотвратить это поведение?
Пробовали ли вы использовать переменную среды рабочего пространства jenkins WORKSPACE (абсолютный путь рабочей области)? При этом ваша строка будет выглядеть примерно так:
sh '${WORKSPACE}/jenkins/pipeline/update-jenkins-plugins-ppln/update-plugins.sh'
Я думаю, ваш pwd не находится в PATH, поэтому вы должны называть его следующим образом: sh './update-plugins.sh'
У меня была такая же проблема. Я думаю, что @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.*"')
}
Папка @tmp предназначена для статистики работы Дженкинса и этапов (продолжительность этапов и т.д.), Вы можете удалить ее, если хотите быть в этом уверены. Я предполагаю, что ваша проблема связана с неверным путем, дважды проверьте ее.
Я предполагаю, что этот конкретный случай не имеет ничего общего с конвейерами 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.