Сервис управления сборкой ПО
Сервис управления сборкой ПО (услуга 1.29) обеспечивает следующую функциональность:
- организация непрерывного процесса сборки и проверки качества исходного кода ПО за счет непрерывного выполнения заданий сборки и проверки качества по событиям изменения кода в Сервисе версионного контроля исходного кода и конфигураций;
- настройка сборки промежуточных и релизных дистрибутивов из исходного кода в Сервисе версионного контроля исходного кода и конфигураций;
- настройка проверки качества исходного кода в Сервисе анализа качества кода;
- настройка проверки корректности сборки дистрибутива приложения за счет выполнения smoke-тестов;
- настройка заданий по выполнению модульных тестов;
- выполнение заданий по сборке и проверке качества исходного кода и дистрибутива;
- сохранение промежуточных и релизных дистрибутивов в Сервисе управления репозиториями дистрибутивов.
Конфигурирование сборок по событию
Основные настройки необходимо сделать на уровне SCM (Git).
Для клонирования обязательно использовать именно протокол ssh, при использовании https сборка автоматически стартовать не будет.
Обратите внимание на pull-requests в названии ветки. Данной ветки физически не существует, и запустить вручную такую сборку невозможно. При модификации запроса на изменение в Сервис управления сборкой ПО передается sha1 коммита, который и будет использован.
Для того, чтобы в Сервисе версионного контроля исходного кода и конфигураций появилась отметка о сборке, надо добавить послесборочный шаг, осуществляющий нотификацию Сервис версионного контроля исходного кода и конфигураций.
Результат
В случае создания нового запроса на изменение в ветку
master Сервис управления сборкой ПО ищет все проекты, которые настроены на ветку pull-requests/master, и запускает их.Результат можно увидеть на странице запроса в Сервисе версионного контроля исходного кода и конфигураций:
- Если сборка не была запущена или завершилась неудачно, то сделать операцию объединения (Merge) для запроса на изменение не получится.
- Если сборка провалилась не по причине изменений в запросе, а, например, из-за ошибки в окружении, то ее всегда можно запустить со страницы запроса на изменение вручную.
Доступные параметры
Из Сервиса версионного контроля исходного кода и конфигураций в Сервис управления сборкой ПО передаются параметры, которые затем могут быть использованы (например, для изменения имени сборки или при рассылке почтовых уведомлений). Эти параметры представлены в таблице ниже.
| Параметр | Описание |
|---|---|
PULL_REQUEST_ID | Идентификатор запроса на изменение (pull-request) |
PULL_REQUEST_URL | URL запроса на изменение |
PULL_REQUEST_TO_BRANCH | Целевая ветка запроса на изменение |
PULL_REQUEST_FROM_BRANCH | Ветка, в которой сделаны изменения |
PULL_REQUEST_FROM_SSH_CLONE_URL | URL репозитория, из которого выполняется PR (в случае, если запрос на слияние делается из потока (workflow) |
Минимальная конфигурация Сервиса обеспечивает:
- максимальное число открытых файлов (параметр
LimitNOFILE) — 8192; - максимальное число процессов (параметр
LimitNPROC, определяет максимально возможное количество запущенных процессов) — 30654. Может уменьшаться в зависимости от ресурсов, потребляемых процессами для обработки запросов Потребителя; - таймаут на формирование HTTP-запроса со стороны клиента после установления соединения (параметр
timeout http-request) — 120 секунд; - таймаут на установление соединения с сервером Gitlab — 10 секунд;
- таймаут на ожидание ответа от сервера Gitlab (параметр
timeout server) — 3 минуты; - максимальное количество соединений (параметр
maxconn, определяет максимально возможное количество соединений со стороны Потребителей, суммарный показатель по всем сервисам Works) — не более 50 000. Может уменьшаться в зависимости от ресурсов, потребляемых соединениями со стороны Потребителя.