Я не профессионал Дженкинс, но из моего опыта, здесь есть много возможных настроек:
Допущения:
По "Automation Framework", яПонимаю, что есть некоторый Java-модуль (созданный Maven, я думаю, что для gradle он будет почти таким же), который имеет несколько тестов, которые в свою очередь вызывают различные API, которые должны существовать «удаленно». Это могут быть HTTP-вызовы, работа с серверами селена и т. Д.
В настоящее время ваша работа в Jenkins выглядит следующим образом (не имеет значения, является ли она работой "старой школы")«пошаговое» определение или Groovy скрипт (конвейеры):
- Оформить заказ из GIT
- запустить
mvn test
- опубликовать результаты теста
Если это так, вам нужно подготовить образ докера, который будет запускать ваш набор тестов (желательно с maven), чтобы воспользоваться преимуществами достоверных отчетов.
Так что вам понадобитсясоздать этот образ докера один раз (см. команду docker build
) и сделать его доступным в частном репозитории / концентраторе докеров в зависимости от того, что предпочитает ваша организация. Технически для этого образа докера вы можете рассматривать образ Java как базовый образ, получитьmaven (загрузить и распаковать + настроить), затем выполнить «команду git pull». Возможно, вы захотите передать учетные данные в качестве системных переменных самому процессу докера (см. флаг «-e»). Главное здесь - maven iПомимо образа докера запустит сборку, поэтому он автоматически разрешит зависимости (вы можете захотеть настроить пользовательские репозитории, если они у вас есть в settings.xml
из maven). Это эффективно отвечает на второй вопрос.
Один тонкий момент - это результаты, которые должны быть каким-то образом показаны в Jenkins: вы можете захотеть поделиться томом с папкой surefire-results
с «хост-машиной» Jenkins, чтобы плагины Jenkins, которыедолжны показать результаты тестов, будут работать. Та же идея применима, если вы используете что-то вроде отчетов об очаровании, спок-отчетов и т. Д.
Теперь, когда образ готов, интеграция с Jenkins может быть такой же простой, как выполнение команды docker run
и ожидание. пока это не сделано. Итак, теперь задание Jenkins будет выглядеть следующим образом:
docker run pre-defined image -e <credentials for git>
show reports
Это один из примеров возможной интеграции.
Один немного другой вариант - запуск сборки Docker в качестве определения задания. Это может быть полезно, если для каждой сборки этот образ должен существенно отличаться, но это замедлит сборку.