Saboteur

service jenkins start

вот на этом моменте нужно найти старт-скрипт дженкинса или его unit файл, и посмотреть что внутри происходит.
Подозреваю, что там тупо лажа с определением как найти запущенный дженкинс. МОжет связано с путаницей местоположения PID файла, или просто кривой скрипт.

На самом деле лучшего тут нет - надо всегда адаптироваться под ваши задачи и ваш проект.
Поднимать дополнительные слейвы в ECS имеет смысл, если у вас много билдов, много тестов, и они стоят денег.

В сложном проекте конфигурация может выглядеть так:
Мастер крутится в своем более-менее стабильном контейнере и рулит исключительно задачами, воркеров не запускает.
Есть несколько видов подготовленных контейнеров для слейвов - для сборки и для тестов, с разной конфигурацией. В некоторых случаях можно даже тут сделать разные контейнеры для сборки nodejs, сборки питона, тестов, и например контейнер для performance тестов.
Во время пайплайна нужные шаги выполняются на нужном слейве, а слейвы динамически поднимаются, если очередь вырастает и также автоматически уничтожаются, когда они не нужны. Например если контейнер поднимается за 1-2 минуты, то при простое в 20-30 минут его можно тушить. Так вы и сократите время билдов, когда их много, и сэкономите деньги на ресурсах, когда они простаивают.

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

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

То, что вы пытаетесь исправить - это баги интеграционного тестирования. Оно исправляется банально тем, что тот кто свой мерж реквест отправил вторым и словил багу - будет разбираться.
Просто на практике, такая ситуация встречается крайне редко при нормальной архитектуре приложения, а поэтому менять весь CI процесс в угоду именно этой фичи и вопреки нормальному git-flow по фичам - это неправильно.

Сложный пример, лень читать столько текста.
Но как минимум, вы не экранируете кавычки вообще. Как я понял,шлете ${CONSUL_HCL_FILE_CONTEXT... как есть, без изменений, а внутри лежат обычные кавычки. Естественно echo с ними не подружится в таком виде.
Разберитесь с экранированием ваших шаблонов.
На крайняк можно вообще кодировать весь файл в base64, передавать как строку, а там декодировать ее в файл.

смотря что за сервер.
Почему нельзя на сервере делать git pull в этой конкретной ветке?

Ну или воспользуйтесь rsync для указанной папки, в которой предварительно git pull был сделан. rsync посмотрит что изменилось.

В настройки Maven на ваших jenkins нодах.
в maven/conf/settings.xml должна быть секция servers с паролями как-то так

<servers>
  <server>
   <id>nexus</id>
   <username>user</username>
   <password>secret</password>
  </server>
</servers>

Ну а причем тут Дженкинс, у вас компиляция xcodebuild падает, Дженкинс его только запускает.

Откомпилируйте вручную, добейтесь чтобы не было ошибки, потом уже можно в дженкинс.

* Попробуйте добавить xcodebuild -verbose, может появится полезная инфа.
* Или вообще обновите версию xcodebuild

Видимо нужно его в гит добавить.
Либо на продакшене есть уже свой env файл, имеющий уникальные настройки для PROD - тогда можно добавить в гит оба варианта, и при деплое проверять какой деплоить.

Также есть вероятность, что в этом файле может быть sensitive данные в открытом виде, тогда его в гит добавлять нельзя.

Задачу для себя подробно составьте и от нее и отталкивайтесь.

Вам говорит, что "openconnect"

не может найти ваш openconnect.
Укажите например полный путь к файлу.

прямо же пишет, что pom.xml не найдет в вашем модуле geckodriverformozilla

А как команда выглядит?
Но в принципе - у вас проблема с доступом по сети.

Пути поправьте. В ваших кракозябрах про это и говорится:

проект "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\ArchitectureTools\Microsoft.VisualStudio.TeamArchitect.ModelingProject.targets" не обнаружен.
Проверьте путь в объявлении и наличие файла на диске.

error MSB4019: импортированный проект "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\DotNet\Microsoft.DotNet.Props" не обнаружен.
Проверьте путь в объявлении и наличие файла на диске.

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