#Trigger

Trigger — это ключевой компонент в Tekton Triggers, который определяет, что происходит при обнаружении события EventListener. Он связывает данные события с выполнением pipeline, задавая, как входящие данные должны обрабатываться, извлекаться и использоваться для создания ресурсов Kubernetes.

#Объяснение терминологии

#Зачем нужен Trigger

#Проблема событийно-ориентированного CI/CD

В традиционных CI/CD системах для связи внешних событий (например, push в Git или вызовы webhook) с выполнением pipeline требуется:

• Пользовательский интеграционный код для каждого источника событий
• Ручная настройка сопоставления данных события с параметрами pipeline
• Сложная логика определения, когда и как запускать конкретные pipeline
• Отдельная обработка для разных окружений и условий

Это приводит к:

• Жёсткой связке между источниками событий и выполнением pipeline
• Дублированию интеграционного кода в разных проектах
• Трудностям в сопровождении и развитии системы
• Ограниченной повторной используемости интеграционных шаблонов

#Как Trigger решает эти проблемы

Tekton Trigger предоставляет декларативный, нативный для Kubernetes способ:

1. Определять логику обработки событий: точно задавать, как должны обрабатываться события без написания кода
2. Извлекать релевантные данные: использовать TriggerBindings для извлечения конкретных полей из полезной нагрузки событий
3. Создавать необходимые ресурсы: применять TriggerTemplates для динамического создания нужных ресурсов на основе данных события
4. Фильтровать и трансформировать события: использовать Interceptors для валидации, фильтрации и преобразования данных события перед обработкой
5. Разделять обязанности: отделять приём событий от создания ресурсов для лучшей сопровождаемости

Такой подход позволяет построить полностью событийно-ориентированную CI/CD систему, которая автоматически реагирует на различные внешние события, сохраняя гибкость и повторную используемость.

#Преимущества

• Декларативная конфигурация: определение связей событие-pipeline с помощью ресурсов Kubernetes
• Повторная используемость: создание переиспользуемых Trigger, применимых в разных проектах
• Гибкость: поддержка различных источников событий (GitHub, GitLab, универсальные webhook и др.)
• Расширяемость: возможность создания кастомных Interceptors для специализированной обработки событий
• Разделение обязанностей: чёткое разделение между приёмом событий, извлечением данных и созданием ресурсов
• Безопасность: встроенная поддержка валидации и фильтрации событий
• Нативность Kubernetes: бесшовная интеграция с экосистемой Kubernetes

#Применимые сценарии

Trigger необходимы в следующих сценариях:

1. Автоматизированные CI/CD pipeline: автоматический запуск сборок и деплоев при push в репозиторий.

2. Мультиокружения: использование одних и тех же данных события для запуска разных pipeline в разных окружениях.

3. ChatOps: выполнение pipeline в ответ на комментарии в pull request или issue.

4. Плановые операции: сочетание с cron job для периодического запуска поддерживающих или тестовых pipeline.

5. Кросс-сервисные workflow: запуск pipeline при событиях в других системах (например, трекерах задач, системах мониторинга).

6. GitOps: автоматическое применение изменений конфигурации при обновлении Git-репозиториев.

#Ограничения и условия

• Для работы Trigger требуется EventListener для приёма и обработки событий
• Каждый EventListener создаёт сервис Kubernetes, доступный для источников событий
• Сложная обработка событий может потребовать кастомных Interceptors
• Источники событий должны иметь возможность отправлять HTTP-запросы на EventListener
• Необходимо учитывать вопросы безопасности webhook (аутентификация, авторизация)

#Принципы

#Структура Trigger

Ресурс Trigger в Tekton имеет следующую структуру:

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: trigger-name
spec:
  # Опционально: обработка и фильтрация событий
  interceptors:
    - ref:
        name: "interceptor-name"
      params:
        - name: "param-name"
          value: "param-value"

  # Извлечение данных из событий
  bindings:
    - ref: binding-name  # Ссылка на существующий TriggerBinding
    # Или встроенный binding
    - name: param-name
      value: $(body.field.path)

  # Указание ресурсов для создания
  template:
    ref: template-name  # Ссылка на существующий TriggerTemplate
    # Или встроенный template
    # spec: ...

  # Опционально: ServiceAccount для создания ресурсов
  serviceAccountName: service-account-name

#Ключевые компоненты и их взаимосвязь

1. Interceptors: обрабатывают входящие события до передачи в bindings и templates

   • Фильтруют события по заданным критериям
   • Преобразуют данные события
   • Добавляют дополнительные данные в полезную нагрузку
   • Проверяют подлинность события

2. Bindings: извлекают данные из полезной нагрузки события

   • Могут ссылаться на существующие TriggerBindings или ClusterTriggerBindings
   • Могут быть встроены непосредственно в Trigger
   • Несколько bindings могут комбинироваться в одном Trigger

3. Template: определяет, какие ресурсы создавать

   • Может ссылаться на существующие TriggerTemplates
   • Может быть встроен непосредственно в Trigger
   • Использует параметры, извлечённые bindings

4. ServiceAccount: предоставляет необходимые права для создания ресурсов

   • Должен иметь разрешения на создание ресурсов, определённых в шаблоне

#Примеры конфигурации

#Trigger для GitHub Pull Request

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: github-pull-request-trigger
spec:
  interceptors:
    - ref:
        name: "github"
      params:
        - name: "eventTypes"
          value: ["pull_request"]
    - ref:
        name: "cel"
      params:
        - name: "filter"
          value: "body.action in ['opened', 'synchronize', 'reopened']"
        - name: "overlays"
          value:
            - key: truncated_sha
              expression: "body.pull_request.head.sha.truncate(7)"
  bindings:
    - name: git-revision
      value: $(body.pull_request.head.sha)
    - name: git-repository-url
      value: $(body.repository.clone_url)
    - name: pull-request-number
      value: $(body.number)
  template:
    ref: pull-request-template

#Trigger для GitLab Push Event

На основе документации по событиям GitLab:

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: gitlab-push-trigger
spec:
  interceptors:
    - ref:
        name: "gitlab"
      params:
        - name: "eventTypes"
          value: ["Push Hook"]
  bindings:
    - name: git-revision
      value: $(body.checkout_sha)
    - name: git-repository-url
      value: $(body.project.git_http_url)
    - name: git- repo-name
      value: $(body.project.name)
    - name: git-commit-message
      value: $(body.commits[0].message)
  template:
    ref: gitlab-ci-template

#Важные пояснения по параметрам, связанным с Trigger

#Interceptors

Interceptors — мощные компоненты, которые обрабатывают события до передачи в TriggerBindings и TriggerTemplates.

#Применимые сценарии

• Проверка подписей webhook
• Фильтрация событий по заданным критериям
• Преобразование данных события
• Добавление дополнительного контекста к событиям

#Ограничения и условия

• Каждый interceptor увеличивает время обработки события
• Сложная логика фильтрации может требовать выражений CEL
• Кастомные interceptors требуют дополнительного развертывания и управления

#Принципы/пояснения параметров

Распространённые interceptors:

• GitHub: проверяет подписи webhook GitHub и фильтрует по типу события
• GitLab: проверяет подписи webhook GitLab и фильтрует по типу события
• BitBucket: проверяет подписи webhook BitBucket и фильтрует по типу события
• CEL: использует Common Expression Language для фильтрации и трансформации
• Webhook: проверяет подписи webhook с использованием секрета

#Bindings

Поле bindings в Trigger задаёт, как извлекать данные из событий.

#Применимые сценарии

• Извлечение информации о коммите Git
• Получение метаданных pull request или merge request
• Получение информации о репозитории
• Доступ к пользовательским заголовкам или полям полезной нагрузки

#Примеры конфигурации

bindings:
  # Ссылка на существующий TriggerBinding
  - ref: common-git-binding

  # Встроенный binding
  - name: custom-field
    value: $(body.custom.field)

  # Ссылка на ClusterTriggerBinding
  - ref: cluster-git-binding
    kind: ClusterTriggerBinding

#Справочные материалы

• Tekton Triggers Documentation
• Trigger Official Documentation
• EventListener Documentation
• TriggerBinding Documentation
• TriggerTemplate Documentation
• Interceptors Documentation