CI/CD: запуск пайплайна при изменении файлов в Git

Настройка автоматического запуска CI/CD-пайплайна при изменении определённых файлов в Git помогает ускорить процесс разработки, сократить время сборки и оптимизировать использование ресурсов. В GitHub Actions, GitLab CI/CD и Jenkins можно настроить запуск всего пайплайна или отдельных этапов только при изменении файлов в конкретных директориях.

В этой статье рассмотрим, как настроить запуск CI/CD по изменённым файлам в GitHub Actions, GitLab CI/CD и Jenkins, а также какие параметры учитывать при работе с инфраструктурным кодом, Terraform, Kubernetes, Ansible и Helm.

1. GitHub Actions: запуск по изменению файлов

В GitHub Actions для управления запуском workflow используются параметры paths и paths-ignore. Они позволяют запускать автоматизацию только при изменении определённых файлов или директорий.

Например, если необходимо запускать инфраструктурный пайплайн при изменении конфигураций в каталогах infra/ и k8s/, можно использовать следующий workflow:

name: Infra Pipelineon:  push:    paths:      - 'infra/**'      - 'k8s/**'  pull_request:    paths:      - 'infra/**'      - 'k8s/**'jobs:  deploy:    runs-on: ubuntu-latest    steps:      - name: Checkout code        uses: actions/checkout@v4      - name: Deploy Infrastructure        run: ./deploy.sh

В этом примере workflow запускается при изменении файлов в директориях infra/ и k8s/ во время push или pull_request.

Преимущества такого подхода:

• Сокращение количества ненужных запусков CI/CD.
• Ускорение обратной связи при работе с pull request.
• Оптимизация использования вычислительных ресурсов.
• Независимый запуск инфраструктурных проверок и развёртывания.

Важно учитывать, что фильтры paths применяются ко всему workflow. Если нужно запускать разные задачи в зависимости от изменённых директорий, можно использовать отдельные jobs и условия их выполнения.

2. GitLab CI/CD: запуск задач при изменении файлов

В GitLab CI/CD для определения изменённых файлов рекомендуется использовать директиву rules: changes. Она позволяет запускать конкретные задачи только при изменении файлов, соответствующих заданным шаблонам.

Пример настройки Terraform-пайплайна:

stages:  - deployterraform:  stage: deploy  script:    - terraform init    - terraform plan    - terraform apply -auto-approve  rules:    - changes:        - terraform/**/*

В данном случае задача terraform будет запускаться при изменении файлов в каталоге terraform/.

В новых конфигурациях GitLab предпочтительнее использовать rules, а не устаревающую директиву only: changes.

При необходимости можно настроить разные задачи для разных компонентов инфраструктуры:

deploy_kubernetes:  stage: deploy  script:    - ./deploy_k8s.sh  rules:    - changes:        - k8s/**/*deploy_ansible:  stage: deploy  script:    - ./deploy_ansible.sh  rules:    - changes:        - ansible/**/*

Теперь изменения в Kubernetes-манифестах будут запускать задачу deploy_kubernetes, а изменения в Ansible-конфигурациях — deploy_ansible.

При настройке GitLab CI/CD важно учитывать контекст запуска пайплайна: правила определения изменений могут отличаться для обычных веток, merge request и новых веток. Для более сложных сценариев применяются compare_to и дополнительные условия rules.

3. Jenkins: запуск отдельных этапов при изменении файлов

В Jenkins Declarative Pipeline можно использовать директиву when с условием changeset. Это позволяет пропускать отдельные этапы сборки или развёртывания, если соответствующие файлы не изменялись.

Пример Jenkinsfile:

pipeline {    agent any    stages {        stage('Deploy Ansible') {            when {                changeset 'ansible/**'            }            steps {                sh './deploy_ansible.sh'            }        }        stage('Deploy Helm') {            when {                changeset 'helm/**'            }            steps {                sh './deploy_helm.sh'            }        }    }}

В этом примере:

• Этап Deploy Ansible выполняется при обнаружении изменений в каталоге ansible/.
• Этап Deploy Helm выполняется при изменении файлов в каталоге helm/.
• Если соответствующих изменений нет, Jenkins пропускает соответствующий этап.

Для корректной работы changeset Jenkins должен располагать информацией об изменениях в Git. Результат зависит от конфигурации SCM, способа checkout и доступности истории коммитов.

Если требуется сравнивать изменения с определённой веткой или управлять условиями на уровне всего пайплайна, можно использовать дополнительные проверки Git и выражения when.

4. Какой CI/CD-инструмент выбрать?

Выбор подхода зависит от используемой платформы и структуры проекта.

Если требуется управлять запуском всего workflow, в GitHub Actions удобно использовать фильтры paths. Если необходимо разделять задачи по компонентам инфраструктуры, подойдут rules: changes в GitLab или when { changeset ... } в Jenkins.

5. Практические рекомендации по настройке CI/CD

Чтобы фильтрация по изменённым файлам работала надёжно, учитывайте несколько важных моментов:

1. Разделяйте инфраструктуру на логические компоненты. Храните Terraform, Kubernetes, Ansible и Helm-конфигурации в отдельных каталогах, чтобы упростить настройку условий запуска.
2. Используйте корректные шаблоны путей. Например, k8s/** или k8s/**/* в зависимости от синтаксиса и назначения фильтра.
3. Учитывайте изменения общих файлов. Если скрипт развёртывания или общий модуль влияет на несколько компонентов, его изменение тоже должно запускать необходимые проверки.
4. Разделяйте проверки и развёртывание. Тестирование, линтинг и проверку конфигураций желательно выполнять до применения изменений в production.
5. Проверяйте поведение в разных сценариях Git. Push, pull request, merge request и создание новой ветки могут иметь разные правила определения изменённых файлов.
6. Не полагайтесь только на фильтрацию запуска. Если обязательные проверки должны выполняться для каждого pull request, настройте обязательные статусы и защиту веток так, чтобы пропущенные задачи не позволяли обойти необходимые проверки.

Заключение

Запуск CI/CD-пайплайна при изменении определённых файлов в Git — эффективный способ оптимизировать автоматизацию разработки и инфраструктурные процессы.

В GitHub Actions для этого применяются paths и paths-ignore, в GitLab CI/CD — rules: changes, а в Jenkins — when { changeset ... }. Правильная настройка этих механизмов позволяет запускать только необходимые проверки и этапы развёртывания, снижать нагрузку на CI/CD-инфраструктуру и ускорять доставку изменений.

Для инфраструктурных проектов особенно полезно разделять пайплайны Terraform, Kubernetes, Ansible и Helm, учитывая при этом общие зависимости и требования к безопасности развёртывания.