Gitlab CI — использование label для управления пайплайнами в небольших командах

Итак, вы — лид в команде из, скажем, 5-6 разработчиков и 2-3 тестировщика, возникает проблема — как тестировать задачи, запускать тесты по веткам, желательно не толкаясь локтями на одном стенде и не потратив недели на настройку и поддержку инфраструктуры. Сегодня расскажу о подходе, к которому сам пришел, оказавшись в такой ситуации.

Первым делом рассмотрим опции:

1. Использование заранее созданных веток для разных целей, скажем, master, dev и test. Этот подход самый простой в реализации, но его минус — он плохо масштабируется. Тестировщикам придется делить один стенд для работы, кроме того, вливать больше одной ветки для тестирования в dev — чревато конфликтами и беспорядком в git. Создавать же еще больше технических веток — еще больший хаос в гите.

2. Собирать каждую ветку в свой полноценный стенд, qa-xxx.dev.xxx.com . Это самый зрелый и удобный для использования вариант, вот только для маленьких команд он непосильно сложен, особенно если среди вас нет девопса. Вам нужно будет разобраться с автоматизацией выдачи SSL сертификатов, настройкой DNS, nginx, подчисткой старых веток и так далее.

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

Для «маршрутизации» веток на инстансы мы используем labels. Выглядит это следующим образом:

Назначение label на ветку автоматически запускает пайплайн с нужными параметрами. Но есть нюанс — оказывается, gitlab не позволяет запускать пайплайны по триггеру на добавление / удаление лейбла. Все, что позволяет gitlab — это выставить ограничение на запуск пайплайна при создании MR, что не совсем подходит — обычно сборка ветки происходит не сразу после его создания.

Хорошая новость в том, что это все-таки возможно — с помощью pipeline triggers и webhooks. Мы просто слушаем события merge request events и триггерим пайплайн в двух случаях: добавление label к ветке и добавление новых коммитов к ветке с нужными label.

Первым делом создаем pipeline trigger token в Settings > CI/CD > Pipeline triggers.

Наш pipeline trigger — по сути микросервис, который принимает вебхуки и по необходимости запускает пайплайны.

const axios = require('axios') var express = require('express'); var router = express.Router();  router.post('/', async function (req, res) {     const requestBody = req.body     const labelRegex = /^test-\d+$/      let label      // If MR is open     if (!['opened', 'locked'].includes(requestBody.object_attributes.state)) {         res.send({             'message': 'invalid status',             'status': requestBody.object_attributes.state         })          return;     }          if (!requestBody.changes.labels) {         // No changes in labels or new commits         if (!requestBody.changes.updated_at && Object.keys(requestBody.changes).length > 0) {             res.send({                 'message': 'The change is empty',             })              return;         }          label = requestBody.labels             .filter(label => label.title.match(labelRegex))             .map(label => label.title)[0]     } else {         // Find a changed label         label = requestBody.changes.labels.current             .filter(label => label.title.match(labelRegex))             .filter(label => !requestBody.changes.labels.previous.find(lbl => lbl.id === label.id))             .map(label => label.title)[0]     }      if (!label) {         res.send({             message: 'label not found'         })          return;     }      await axios.post(`https://gitlab.com/api/v4/projects/${process.env.PROJECT_ID}/trigger/pipeline`, {         token: process.env.ACCESS_TOKEN,         ref: requestBody.object_attributes.source_branch,         variables: {             TEST_INSTANCE: label,             CI_MERGE_REQUEST_LABELS: requestBody.labels?.map(label => label.title).join(',') ?? ''         }     })              res.send({         'message': 'success'     }) });  module.exports = router;

Осталось только добавить вебхук в гитлабе в Settings > Webhooks:

Gitlab предоставляет доступ к логам, так что в случае проблем их можно довольно легко отладить:

Все! Теперь просто присвойте label test-N вашей ветке и вебхук запустит пайплайн. Из приятных бонусов: скрипт также передает все остальные назначенные label-ы через запятую, что позволяет дополнительно задавать на лету переменные окружения, например, вы можете через label управлять, пересоздавать ли БД с нуля или использовать сохраненные данные, и так далее.

Заключение

Конечно, этот способ не идеален и масштабируется лишь ограниченно. Если вам не хватает пяти стендов для тестирования, возможно, вам стоит задуматься о более продвинутой схеме. Однако, для небольших команд подход обеспечивает неплохой development experience, позволяет полноценно тестировать в независимых окружениях и не накладывает ограничений на разработку.