Консоль сценариев Дженкинса против агента сборки

#jenkins #jenkins-pipeline #jenkins-groovy #progress-4gl #jenkins-job-dsl

#Дженкинс #дженкинс-конвейер #дженкинс-заводной #прогресс -4gl #дженкинс-задание-dsl

Вопрос:

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

Все работает отлично, за исключением одной проблемы — служба больше не запускается после завершения сборки. Я даже добавил несколько отладочных сообщений после перезапуска сценария, чтобы доказать с помощью выходных данных сборки, что это действительно работает. Но по какой-то причине после завершения сборки служба больше не запускается. Я провел обширное тестирование, чтобы убедиться, что Дженкинс подключается к удаленному хосту как правильный пользователь, имеет правильный набор переменных env и т.д. Кроме того, вывод сценария перезапуска в первую очередь очень подробный — не было бы никакого способа получить успешный вывод, если бы он на самом деле не работал. Итак, я предполагаю, что процесс, который выполняет шаги развертывания на удаленном хосте, выполняет что-то еще после завершения сборки. Выполнение.

Вот где это становится странным: если я запускаю те же точные команды развертывания с помощью консоли сценариев для того же самого удаленного хоста, это работает. И служба не останавливается после успешного запуска.

Под «таким же точным» я подразумеваю, что сценарий тот же, но DSL отличается между консолью сценариев и конвейером. Например, в консоли сценариев я использую

println "deployscript.sh <args>".execute().text

В то время как в конвейере я использую

 pipeline {
  agent {
    node 'mynode'
  }
  stages {
    /*other stages commented out for testing*/
    stage('Deploy') {
      steps {
        script {
            sh 'deployscript.sh <args>'
        }
      }
    }
  }
}
  

У меня также нет проблем с запуском команд вручную через SSH.

Кто-нибудь знает, что здесь происходит? Есть ли разница в том, как консоль сценариев и агент сборки подключаются к удаленному хосту? Выполняет ли какой-либо из этих процессов другие команды? Я понимаю, что сеанс SSH контролируется процессом Java, но я мало что знаю о реализации Дженкинса.

Если кому-то интересно узнать о самом приложении, это сервер приложений Progress для экземпляра OpenEdge (PASOE). Процесс развертывания включает в себя отмену развертывания старого файла WAR, развертывание нового, а затем остановку / запуск экземпляра.

ОБНОВЛЕНИЕ: я добавил 60-секундный режим ожидания в конце сценария развертывания, чтобы дать мне время протестировать службу до завершения процесса Дженкинса. Это было успешно, поэтому я уверен, что когда завершается процесс сборки Дженкинса, это приводит к отключению службы. Я не уверен, что это проблема с Дженкинсом, владеющим процессом, но, опять же, консоль сценариев отлично справляется с этим…

Комментарии:

1. Звучит так, что я бы обратился в службу поддержки PSC по поводу Джона. Особенно потому, что на данный момент они довольно популярны на CI / CD и т.д.

Ответ №1:

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

Исправление заключается в том, чтобы установить значение переменной среды BUILD_ID (JENKINS_NODE_COOKIE для конвейера, как в моей ситуации) в «dontKillMe».

Например:

 pipeline {
  agent { /*set agent*/ }
  environment {
    JENKINS_NODE_COOKIE="dontKillMe"
  }
  stages { /*set build stages*/ }
}
  

Смотрите здесь для получения более подробной информации:https://wiki.jenkins.io/display/JENKINS/ProcessTreeKiller