В этой статье я расскажу о том, как быстро построить конвейер, который будет выборочно запускать команды в разных каталогах репозитория только в случае обнаружения изменений. В этой статье я предполагаю некоторые базовые знания CircleCI, однако я пройду весь процесс с самого начала настройки проекта.
- Настройка проекта
Начните с входа в CircleCi, в этом примере я войду с помощью Github SSO и выберу проект, для которого вы хотите настроить конвейер. Здесь вам предоставляется несколько вариантов, все в порядке, однако я предпочитаю средний вариант Faster: Commit a started CI pipeline to a new branch. Этот вариант создаст новую ветку в проекте с примером файла .circleci/config.yml, который затем можно объединить в основную ветку проекта. В качестве альтернативы вы можете войти и создать этот каталог и файл самостоятельно, зафиксировать их в основной ветке и использовать опцию Fastest:Use the .circleci/config.yml in my repo и ввести ветку, в которой вы это создали, в текстовое поле.
2. Пример структуры проекта
В этом примере у нас будет 3 папки в нашем корневом каталоге:
.circleci/ — Здесь мы будем хранить конфигурации CircleCi.
test1/ — Один из каталогов, которые мы будем тестировать, если будут обнаружены изменения
test2/ — Один из каталогов, которые мы будем тестировать, если будут обнаружены изменения
Примечание. В этом примере я буду использовать Go, чтобы продемонстрировать выборочное выполнение тестов.
3. Настройка CircleCi
В этом разделе я расскажу о том, что требуется для нашей конфигурации CircleCi. Для настройки выборочного запуска мы будем использовать два файла: базовый файл config.yml, а затем, в этом примере, файл с именем testing.yml.
Config.yml
Ниже приведено изображение исходного файла конфигурации, который нам понадобится. Этот файл указывает нашему конвейеру отслеживать определенные каталоги, и при обнаружении изменений мы передаем параметр в нашу постоянную конфигурацию, найденную в testing.yml.
Прогулка по изображению выше:
setup: true требуется, чтобы вы могли использовать функцию динамической конфигурации CircleCI.
orbs: pathfiltering: circleci/[email protected]Это сфера, необходимая для продолжения конвейера в зависимости от пути к обновленному файлу.
always-run: гарантирует, что этот рабочий процесс всегда запускается.
- path-filtering/filter: — это задание фильтрации пути, в котором мы будем сопоставлять каталоги, которые мы хотим отслеживать на наличие изменений.
mapping: Принимает 3 параметра, разделенных пробелами — ‹регулярное выражение для отслеживания, параметр для установки, значение для установки›.
base-revision: main Ветвь, с которой мы хотим сравнить при проверке заданных сопоставленных каталогов.
config-path: Файл продолжения, который мы хотим использовать в нашем конвейере.
testing.yml
На изображении ниже мы объявляем ожидаемые нами параметры, в данном случае run-test-1 и run-test-2 — это параметры, переданные при сопоставлении в исходном файле конфигурации. Затем мы, в зависимости от значения этих параметров (Обнаружены изменения: Истина, Без изменений: Ложь), запускаем нужные рабочие процессы.
Пройдитесь по изображению выше:
parameters: Параметры, которые мы ожидаем передать через конвейер, объявлены в разделе сопоставления начальных файлов конфигурации.
jobs/workflows Изучение самых основ работы заданий и рабочих процессов выходит за рамки этой статьи, но краткая версия — это рабочий процесс, представляющий собой список заданий, а задания — набор шагов, которые выполняются в одном блоке (контейнер/виртуальный компьютер). ) в случае этого примера запуска тестов кода нашего примера в контейнере докеров.
when: << pipeline.parameters.run-test-1/2 >> Это говорит нашим рабочим процессам запускать следующие задания только в том случае, если для объявленного параметра конвейера установлено значение true.
На изображении ниже я фиксирую изменения только в каталоге test2, затем это обнаруживается, и конвейер будет тестировать только необходимый код.
В то время как на следующем изображении я фиксирую изменения в обоих каталогах, и снова это обнаруживается, а затем тестируются все.
4. Заключительные замечания
Предыдущие примеры очень просты, однако концепция, продемонстрированная здесь, может быть перенесена и использована во многих различных ситуациях. Хорошим примером этого может быть монорепозиторий, используя приведенную выше конфигурацию, вы можете отслеживать каждый отдельный пакет в монорепозитории и запускать рабочие процессы только в пакетах с новыми изменениями — экономя деньги и время.
Код для приведенных здесь примеров можно найти ниже:
Повышение уровня кодирования
Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:
- 👏 Хлопайте за историю и подписывайтесь на автора 👉
- 📰 Смотрите больше контента в публикации Level Up Coding
- 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"
🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу
