Перейти на PRO

Какие типы триггеров для CI/CD пайплайнов вы настраивали и для каких задач?

Тип вопроса: DevOps Вероятность: 10% Категория: Golang Разработчик

Ответ

Да, я настраивал различные триггеры в CI/CD системах, в основном в GitHub Actions и GitLab CI. Выбор триггера зависит от конкретной задачи и рабочего процесса.

Вот основные типы триггеров и их применение на моем опыте:

  1. При коммите или Pull Request (on: [push, pull_request])

    • Задача: Гарантия качества кода. Это основной триггер для запуска тестов, линтинга и сборки приложения при каждом изменении в ветках main, develop или в feature-ветках, на которые создаются Pull Request.
    • Пример (GitHub Actions): 
      on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

  2. По расписанию (on: schedule)

    • Задача: Выполнение регулярных, фоновых задач.
    • Примеры использования:
      • Запуск долгих E2E-тестов в ночное время, чтобы не замедлять основной CI.
      • Ежедневное сканирование зависимостей на уязвимости.
      • Генерация периодических отчетов.
    • Пример (ежедневно в 3:00 UTC): 
      on:
schedule:
- cron: '0 3 * * *'

  3. Вручную (on: workflow_dispatch)

    • Задача: Запуск пайплайна по требованию, обычно для контролируемых действий.
    • Примеры использования:
      • Деплой приложения на staging или production окружение.
      • Запуск ресурсоемкой задачи, например, миграции данных.
    • Пример: 
      on: workflow_dispatch

  4. По событию в репозитории (например, создание тега или релиза)

    • Задача: Автоматизация процессов релиза.
    • Пример использования: При создании нового тега (например, v1.2.0) автоматически собирается релизный артефакт, публикуется Docker-образ и создается GitHub Release.
    • Пример (при создании тега): 
      on:
push:
tags:
  - 'v*.*.*'

В GitLab CI для более сложных условий я использовал директиву rules, которая позволяет гибко комбинировать условия запуска, например: запускать только для тегов И только если переменная окружения установлена.

Ответ 18+ 🔞

Слушай, я тут настраивал эти ваши триггеры в CI/CD, ну, в GitHub Actions и GitLab CI. Ну, блядь, выбор-то зависит от того, какую конкретно задачу решаешь, и как у тебя там рабочий процесс устроен, понимаешь?

Вот, смотри, какие основные типы бывают и где я их применял, на своём горьком опыте:

  1. На каждый коммит или Pull Request (on: [push, pull_request])

    • Зачем это надо: А вот это, блядь, чтобы качество кода не проёбывать. Основной триггер, сука. Запускаешь тесты, линтинг и сборку каждый раз, когда кто-то что-то закоммитил в main или develop, или когда создают Pull Request. Чтобы всякую хуйню не залили, блядь.
    • Вот, смотри, как это выглядит (GitHub Actions): 
      on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

  2. По расписанию, как будильник (on: schedule)

    • Зачем это надо: Для всяких регулярных, фоновых дел, которые не надо делать на каждом чихе.
    • Где я это юзал, ёпта:
      • Долгие E2E-тесты гонять ночью, чтобы днём пайплайн не тормозил, как черепаха в сиропе.
      • Ежедневно проверять зависимости на дыры, вдруг там какая уязвимость вылезла.
      • Отчёты там всякие генерить.
    • Пример (каждый день в 3 утра по UTC, чтобы никого не ебало): 
      on:
schedule:
- cron: '0 3 * * *'

  3. Ручной запуск, по кнопке (on: workflow_dispatch)

    • Зачем это надо: Когда нужно всё под контролем, по щелчку пальцев. Не каждый день, а когда сам решил.
    • Где пригождалось:
      • Деплой на staging или, мать его, на production. Тут уж точно на авось не понадеешься.
      • Запустить какую-нибудь тяжёлую хуйню, типа миграции данных, чтобы всё не легло в пизду.
    • Вот так просто: 
      on: workflow_dispatch

  4. По событию в репозитории (типа, создали тег или релиз)

    • Зачем это надо: Чтобы автоматизировать весь этот цирк с выпуском версий.
    • Как юзал: Создали новый тег, например, v1.2.0 — и тут же автоматом собирается релизный артефакт, Docker-образ выкладывается и релиз в GitHub создаётся. Красота, блядь!
    • Пример (ловим все теги по маске): 
      on:
push:
tags:
  - 'v*.*.*'

А в GitLab CI, там, блядь, ещё есть такая мощная штука — rules. Она позволяет такие условия накрутить, что мама не горюй! Типа, «запускайся только для тегов И только если вот эта переменная окружения установлена». Гибко, ёпта, очень гибко.

© ХакСобесов, 2026
support@hacksobesov.com