Как запустить репо из скрипта внутри контейнера в задании Дженкинса - PullRequest
0 голосов
/ 02 ноября 2018

Я не могу запустить репо неинтерактивно внутри контейнера как часть работы вольным стилем.

Он запрашивает имя пользователя и адрес электронной почты. Я обошел это, сделав git config --global внутри работы.

Но тогда он делает цветовой тест, и это висит бесконечно.

Глядя на исходный код репо, я вижу это

if os.isatty(0) and os.isatty(1) and not self.manifest.IsMirror:
      if opt.config_name or self._ShouldConfigureUser():
        self._ConfigureUser()
      self._ConfigureColor()

Итак, я запустил в контейнере следующее:

python -C "import os; print os.isatty(0), os.isatty(1)"

и, конечно же, распечатано True True

Глядя на журнал Jenkins, он запускает контейнер с указанным --tty, и, похоже, нет способа настроить этот параметр.

Я не могу найти опцию bash для принудительного запуска скрипта в неинтерактивной оболочке. Если я помещу приведенную выше строку python в файл и выполню ее практически с любой комбинацией команд и опций, она все равно выведет True True

Только , если я вижу что-то другое, это если я использую перенаправление ввода / вывода

bash <a.sh

который печатает False True - т.е. stdin не tty, а

bash <a.sh >a.log

который печатает False False.

Для сложного сценария есть ли проблемы с использованием подхода bash <script?

Кто-нибудь знает магию Дженкинса, чтобы предотвратить запуск докера с помощью --tty?

Я знаю, что --tty является виновником. Я построил контейнер локально и запустил следующее

$ docker run repotest python -c "import os;print os.isatty(0), os.isatty(1)"
False False
$ docker run --tty repotest python -c "import os;print os.isatty(0), os.isatty(1)"
True True

Работающие версии:

  • репо: 1.12.37 (для Ubuntu 16.04 apt-get)
  • Дженкинс: 2,149
  • Плагин Cloudbees Docker: 1.7.3
  • Контейнерная база Ubuntu: xenial

Я использую опцию "Построить внутри контейнера докера".

1 Ответ

0 голосов
/ 05 ноября 2018

Для запуска скрипта bash repo_script.sh "неинтерактивно", или, точнее говоря, без терминалов, связанных со стандартными потоками, вы можете запустить свой скрипт просто как

 repo_script.sh < /dev/null 2>&1 | cat

при условии, что вы хотите видеть вывод таким, каким вы видите его, просто как repo_script.sh. При передаче стандартного вывода и ошибки в другой процесс дескриптор файла отображается в виде канала, а не TTY в repo_script.sh. Вы также можете направить вывод в файл или даже на /dev/null, если вам не нужен вывод:

 log_file=/dev/null
 repo_script.sh < /dev/null > "${log_file}" 2>&1

Запуск скрипта от имени

 bash < repo_script.sh | cat

может также сработать, хотя это очень неортодоксальный и, на мой взгляд, хакерский способ запуска скрипта просто для того, чтобы разорвать связь TTY со стандартным вводом. С точки зрения механизма сценариев, чтение программы сценария из файла отличается от стандартного ввода (который обычно, если это терминал, не доступен для поиска), поэтому могут быть некоторые тонкие различия, которые может возможно, кусает тебя неожиданным образом. Этот способ не так четко передает ваше намерение следующему человеку, которому необходимо понять ваш код, и может привести к частичному выпадению волос у этого человека из-за постороннего царапин на голове.

Нет необходимости в каких-либо параметрах bash, просто использование выходных инструкций из интерпретирующей оболочки, как описано выше, представляет собой простое для понимания многоплатформенное совместимое стандартное соглашение для изменения стандартных ассоциаций потоков.

P.S. Я думаю, что для вашего сценария репо должно быть достаточно просто проверить, является ли стандартный ввод TTY. Мне кажется, что автор этого сценария не думал достаточно глубоко там. Просто не стоит ждать ввода, если у вас нет терминального устройства, связанного со стандартным вводом, и вы можете определить, что все должно работать без вмешательства пользователя, или остановиться с ошибкой, если это невозможно.

...