У нас есть некоторый код в подпапке репозитория, который используется в качестве исходного шаблона для новых репозиториев, которые сами имеют свой полный конвейер CI / CD и могут быть развернуты на сервере и выполнять работу.
Было бы очень полезно провести дополнительное автоматическое тестирование, запустив конвейер сборки / развертывания Jenkins исходного репозитория (как записано в Jenkinsfile) для этой подпапки без предварительного создания из нее нового репо. Единственная проблема в том, что есть некоторые заполнители шаблонов, которые должны иметь значения, введенные до того, как будет работать сборка / развертывание.
В идеале, лучший сценарий - использовать точный сценарий конвейера Jenkinsfile из папки шаблонов. Однако создание задания конвейера Jenkins, наивно указывающего на то, что Jenkinsfile, похоже, не будет работать, потому что:
- Jenkinsfile не будет знать, как выполнить сборку для подпапки вместо root и Jenkinsfile действительно не должен меняться - он должен работать, когда код выполняется в своем новом, шаблонизированном репо.
- Шаблонизация еще не была выполнена, поэтому папка шаблона не может на самом деле быть построенным и развернутым без небольшой модификации, потому что значения будут неправильными или недействительными.
Я потратил некоторое время, пытаясь выяснить, как этого добиться, и до сих пор не получался. Вот что я пробовал или исследовал / думал:
Разделите шаблон Jenkinsfile на две части, часть the pipeline {} и часть steps {}, затем создайте новое конвейерное задание с пользовательский Jenkinsfile, который пытается загрузить файл шагов. Это не сработало, потому что вы не можете вызвать шаг изнутри шага, и вы не можете запустить любой скрипт, который запускал бы другой файл groovy (который я смог выяснить) вне шага. Это не было бы идеально, потому что тогда шаблонное приложение разделило бы свой Jenkinsfile на две части, и сценарий тестирования не использовал бы точный тот же сценарий конвейера, но это было бы полезно.
Создайте проект вольным стилем, который выполняет проверку SCM, вносит все необходимые изменения локально (быстро моделирует полный процесс шаблонизации без необходимости создания нового хранилища), вносит изменения в шаблон шаблона. папку (и, возможно, измените рабочий каталог или переместите файлы / удалите их при необходимости, чтобы шаблонное приложение находилось в root), а затем запускает существующий сценарий конвейера Jenkinsfile, который должен работать оттуда. Я попробовал это, но не могу понять, как запустить конвейерную работу непосредственно из проекта фристайла.
Создайте проект фристайла, который выполняет тот же процесс, что и выше, а затем сохраняет артефакты затем создайте еще одно конвейерное задание, которое использует эти артефакты в качестве источника сборки. Но я даже не уверен, возможно ли это, и я уже потратил слишком много времени на исследование этого вопроса.
Выполните быстрый процесс шаблонизации, и в каждой сборке создайте новую ветвь (возможно, названный номером сборки) в каком-то репозитории для этой цели, а затем запуск нижестоящего конвейерного задания, которое использует эту ветвь в качестве источника. Это может сработать, но привносит кучу дополнительной сложности и внешнюю зависимость от репо, которая затем будет иметь кучу веток, нуждающихся в очистке, требующих другого задания, которое не всегда может работать успешно, само по себе. Было бы здорово, если бы вам не пришлось этого делать.
Дублируйте шаблон Jenkinsfile в другом месте родительского репозитория и автоматически добавьте необходимые шаги для его шаблонизации и использования подпапки. Тем не менее, это далеко от идеала, потому что тогда мы используем код для написания кода нестандартным способом (огромный источник ошибок / поломок), а также, почти один и тот же код должен быть в двух местах, и различия могут заползать между два файла Jenkins, которые должны быть идентичными в большинстве частей.
В некоторых процессах сборки на стороне разработчика для обработки извлеките Jenkinsfile шаблона, внедрите подпапку и шаблонизирующие изменения и сохраните ее копию в другом месте, чтобы зафиксировать ее с любыми другими изменениями. НЕ идеальный. Сгенерированные файлы не должны быть зафиксированы, и это создает нагрузку для разработчиков и может быть трудно осуществимым - кажется хрупким и не очень хорошей стратегией для фактического предотвращения различий между двумя файлами Jenkinsfiles. Все та же проблема с кодом написания кода.
Добавьте автоматические коммиты в родительское репо, которые обновляют копию Jenkinsfile, вместо того, чтобы заставлять разработчика делать это. В то время как изменения в Jenkinsfile не часты, такие дополнительные коммиты уродливы, и у этого есть много тех же проблем, которые перечислены в предыдущих идеях.
Вот и все - пока я из идей.
Какой-нибудь совет о том, как добиться того, что я ищу, без особых сложностей или работы?
Справочная информация: сейчас у нас нет любые автоматические тесты для определенных частей шаблона, поскольку для полного тестирования всех частей требуется не просто создание или запуск модульных тестов, а фактическое развертывание (шаблонного) приложения на сервере для тестирования самого кода развертывания, а также запуск сквозной работы тесты на успешно развернутый результат. В идеале долгосрочное решение - это запустить процесс создания нового репо, а затем выполнить тесты оттуда, но это потребует много времени и работы, чтобы полностью автоматизировать создание / шаблонизацию, тестирование и демонтаж. Кроме того, необходимо будет заставить репозиторий исходных кодов дождаться завершения всего этого тестирования, прежде чем собственный процесс тестирования будет отмечен как успешный. Таким образом, быстрое решение, которое получает большую часть пользы от простого развертывания приложения как есть из его подпапки (с незначительным выполнением шаблонов), было бы действительно здорово. В долгосрочной перспективе мы уходим от Дженкинса, но нужно это тестирование сейчас!