У меня есть скрипт, который отлично работает локально. Но когда я запускаю его в Jenkins, я получаю Ошибка: запись вывода не удалась: сломанная труба
.
Мой вопрос: как исправить это, чтобы оно работало в jenkins?
Теперь контекст, который поможет ответить на вопрос. Фактический канал: somevar=$(jq --arg host "${HOSTNAME}" --arg id "${ID}"'.[] | select((.hostname==$host) and (.порт==XXXX)).serviceId = $id' <<<"${MYJSON}" | jq -s)
.
Jenkins версии 2.164.3
Jenkins bash версии 4.2
Jenkins OS CentOS 7
Локальный bash версии 5
Local OS Arch Kernel версии 5.0
Я также успешно запустил этот скрипт в док-контейнер отлично подходит для следующих спецификаций;
Container OS Ubuntu 18.04
Bash 4.4
Итак, если вы не можете ответить на мой вопрос, возможно, вы можете пролить свет на то, почему это может работать в других средах, но не в Jenkins. Или, может быть, вы можете предложить способы устранения этой проблемы? В настоящее время я думаю об использовании ловушки
, чтобы получить больше информации? Но я точно не знаю, как я могу это сделать.
Идите и найдите, какая из программ, вызывающих ваш сценарий, настраивает обработчик сигнала SIGPIPE
на игнорирование. (ищите trap '' PIPE
и т. д. ). Расположение сигнала «игнорировать» наследуется дочерними процессами.
В любом конвейере, таком как ... | head -5
, абсолютно нормально, что левая сторона конвейера получает SIGPIPE
и из-за этого завершается чисто и без шума. Если он проигнорирует или перехватит SIGPIPE
, системный вызов write()
вернется с ошибкой EPIPE
или в переводе «Сломанный канал».
Многие дрянные программы не проверяют успешность выполнения write()
--, что означает, что установка SIGPIPE
на игнорирование может быть вектором атаки при вызове исполняемых файлов setuid.
Но это не случай jq
, который должным образом информирует вас о неожиданном условии (, которое, скорее всего, не сделает его вывод другим ).
Но я не пользуюсь Дженкинсом и не люблю его, так что больше ничем помочь не могу. Хотя я очень сомневаюсь, что это вина Дженкинса.