Что такое CI (Continuous Integration)

Ссылка на ХАБР (там кликабельное содержание! В блоге такое не сделать)

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.

Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Варианты настройки системы CI

Неважно, какую именно систему CI (Continuous Integration) вы используете — Jenkins, TeamCity, или какую-то другую. Для всех них можно использовать варианты настройки:

• от операционной системы
• от плагинов

От операционной системы

Мы подготавливаем операционную систему машины, на которой будут гоняться автотесты.

Вот, скажем, в официальной инструкции Postman-а есть статья «Integration with Jenkins». Что нужно сделать, чтобы запустить тесты в Jenkins:

• Установить Jenkins
• Установить на ту же машину NodeJS и npm
• Установить на ту же машину newman

Установили? Теперь очень легко конфигурировать задачи — добавил shell-команду, а внутри нее вызов newman. И всё, ничего лишнего!

Интеграция Jenkins с private-репозиторием в Bitbucket

Если у нас публичный репозиторий, то достучаться до него в Jenkins проблем вообще нет, в pipeline скрипте указываем:

git 'https://okiseleva@bitbucket.org/testbasecode/test_1.git' 

И готово!

А что, если у нас приватный репозиторий? Что, собственно, и будет на реальной работе, кто ж свои автотесты в общий дотуп то кладет =))

Подключать надо через SSH-ключ. Для этого идем в битбакете в настройки проекта —  General— Access keys. И там будет ссылка на актуальную инструкцию!

Сейчас эта ссылка ведет сюда — https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html

Я настраивала для Linux. Ой, ну ладно, муж настраивал, не суть ツ
Шаги настройки:

Разграничение доступа по папкам Jenkins-а

Как сделать так, чтобы новый пользователь в Jenkins имел доступа только к части проектов? При этом мог создавать задачи и конфигурировать их. Для этого надо разбить проекты на папочки и раздавать права на директорию. Как?

Устанавливаем плагин — Folder-based Authorization Strategy.

Тогда в настройках дженкинса появится стратегия авторизации в папках:

Открываем ее, переходим в раздел «Manage Folder Roles» (над ним еще глобальные настройки есть, там можно дать view доступ)

Удаленный запуск джобы в Jenkins через curl

В Jenkins есть возможность запускать задачи удаленно, через curl:

curl -X POST http://API_USER_ID:API_TOKEN@JENKINS_URL/job/JOB_NAME/build -H "CRUMB"

А вот как составить этот curl, мне помогла статья на stackoverflow, которая, в свою очередь, ссылается на оригинальный пост.

Хочу сохранить это решение:

Допустим, мы хотим запустить удаленно задачу под названием «Football».
Дженкинс у нас находится по адресу http://192.168.99.20:8080 и входим ты под пользователем admin.

Что нужно сделать?

1. Создать задачу

1. «Создать Item» (да, в русифицированной версии это так называется)

Со свободной конфигурацией, назвать «Football». 

Хочу заметить, что, если вы собираетесь вызывать джобу через curl, лучше не использовать пробел в ее названии. А то потом огребете проблем там, где не ждали. Это имхо, но лучше использовать CamelCase  или snake_case.

См также:

CamelCase, snake_case и другие регистры

Ошибка в Jenkins: newman: command not found

Установил мне админ Jenkins на моем сервере. Стала настраивать связку с Postman по инструкции — «Integration with Jenkins».

Вроде установила и nodejs, и newman. Запускаю тест, а он мне обломчик:

Started by user Админ 
Running as SYSTEM
Building in workspace /var/lib/jenkins/workspace/Newman_test
[Newman_test] $ /bin/sh -xe /tmp/jenkins166732700398555443.sh
+ newman run https://www.getpostman.com/collections/c2eb72db4c1191c3d36d
/tmp/jenkins166732700398555443.sh: 2: /tmp/jenkins166732700398555443.sh: newman: not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE

Но как это «newman: not found»?? Ведь если зайти через SSH на сервер и запустить ту же самую команду

newman run https://www.getpostman.com/collections/c2eb72db4c1191c3d36d

То все работает!