#ScheduledTrigger

ScheduledTrigger добавляет автоматизацию, похожую на cron, в Tekton Triggers. Вместо ожидания внешних вебхуков вы можете попросить платформу запускать TriggerTemplate по повторяющемуся расписанию, при этом опционально учитывая конкретный часовой пояс и подставляя параметры, зависящие от времени, в каждый запуск.

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

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

#Проблемы автоматизации на основе времени

• Команды часто используют Tekton вместе с ad-hoc CronJobs, shell-скриптами или внешними планировщиками только для запуска периодических пайплайнов.
• Операционные задачи (ночные сканирования, еженедельные очистки, отчёты в конце месяца) требуют стабильного времени запуска и прозрачности.
• Перекрывающиеся cron-задачи и ручные скрипты увеличивают затраты на поддержку и усложняют аудит.

#Как помогает ScheduledTrigger

ScheduledTrigger объединяет планирование и выполнение пайплайнов в одной системе:

1. Единое определение – объявляйте интервал, часовой пояс и шаблон в одном манифесте.
2. Паритет событий – TriggerTemplates запускаются так же, как если бы их вызвал EventListener, поэтому downstream-инструменты, RBAC и мониторинг работают одинаково.
3. Контекстная осведомлённость – каждый запуск получает структурированные временные метки, что позволяет детерминированно именовать, формировать отчёты или разбивать данные.
4. Встроенный catch-up – при перезапуске контроллера он может воспроизвести пропущенные тики до разумного предела, снижая необходимость ручного вмешательства.

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

• Декларативное планирование с использованием нативных CRD Kubernetes.
• Контроль часового пояса для обеспечения запуска ночных задач в рабочее время в любой точке мира.
• Последовательная параметризация через контекстные плейсхолдеры и пользовательские параметры.
• Меньше вспомогательного кода — не нужны дополнительные CronJobs или прокладки для вебхуков.
• Единый мониторинг: события, статус и логи находятся рядом с другими ресурсами Tekton.
• Безопасные повторы благодаря контролируемому поведению catch-up для пропущенных запусков.

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

1. Ночные регрессионные тесты или сканирования безопасности, которые должны запускаться даже при отсутствии активности в Git.
2. Рабочие процессы обслуживания, такие как очистка кэша, ротация ресурсов или экспорт баз данных.
3. Задачи соответствия и аудита, которые должны запускаться по фиксированному календарному расписанию.
4. Гибридная автоматизация, когда пайплайны, запускаемые вебхуками, дополняются периодическими базовыми запусками.
5. Синхронизация окружений, поддерживающая актуальность staging или demo окружений.

#Ограничения и лимиты

• ScheduledTrigger принимает cron-выражения, поддерживаемые robfig/cron (стандартная форма из пяти полей).
• В TriggerTemplates поддерживаются только строковые параметры; сложные данные нужно преобразовывать в строки перед передачей.
• Число пропущенных тиков ограничено, чтобы защитить кластеры от всплесков накопленных запусков.
• Названия часовых поясов должны совпадать с записями в базе TZ, доступной внутри контейнера контроллера.
• ScheduledTrigger ориентирован на выполнение TriggerTemplate. Для обычных Pod без контекста Tekton предпочтительнее использовать Kubernetes CronJobs.

#Как работает ScheduledTrigger

1. Определите расписание – укажите cron-выражение и (опционально) часовой пояс. Контроллер рассчитывает следующее время запуска на основе этих значений.
2. Привяжите TriggerTemplate – укажите ссылку на существующий шаблон или встроите его inline. Каждый тик рендерит шаблон с актуальной спецификацией, поэтому обновления применяются автоматически.
3. Передайте параметры – используйте статические значения или контекстные плейсхолдеры. $(context.date) разрешается в YYYY-MM-DD, а $(context.datetime) — в метку времени RFC3339 запланированного запуска.
4. Выполнение контроллера – при каждом тике контроллер создаёт ресурсы, определённые в TriggerTemplate, и записывает время последнего запуска в статус ресурса.
5. Мониторинг – события Kubernetes сообщают об успехе или ошибке, позволяя стандартным инструментам (kubectl, дашборды) отслеживать запланированные запуски.

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

#Простой ScheduledTrigger

apiVersion: tekton.alaudadevops.io/v1alpha1
kind: ScheduledTrigger
metadata:
  name: nightly-security-scan
  namespace: cicd
spec:
  schedule: "0 2 * * *"          # Каждый день в 02:00
  triggerTemplate:
    ref: security-scan-template
  params:
    - name: scan_date
      value: "$(context.date)"
    - name: environment
      value: "production"

#Расписание с учётом часового пояса

apiVersion: tekton.alaudadevops.io/v1alpha1
kind: ScheduledTrigger
metadata:
  name: weekly-cleanup
spec:
  schedule: "30 3 * * 1"         # По понедельникам в 03:30
  timeZone: "Europe/Paris"
  triggerTemplate:
    ref: cleanup-template

#Встроенный TriggerTemplate

apiVersion: tekton.alaudadevops.io/v1alpha1
kind: ScheduledTrigger
metadata:
  name: refresh-demo-data
spec:
  schedule: "0 */6 * * *"        # Каждые 6 часов
  triggerTemplate:
    spec:
      params:
        - name: target_cluster
          default: "demo"
      resourcetemplates:
        - apiVersion: tekton.dev/v1
          kind: PipelineRun
          metadata:
            generateName: refresh-demo-
          spec:
            pipelineRef:
              name: refresh-pipeline
            params:
              - name: cluster
                value: "$(tt.params.target_cluster)"

#Важные пояснения к параметрам

#schedule

Использует стандартный формат cron минуты часы день-месяца месяц день-недели. Значение этого поля соответствует синтаксису Cron.

# ┌───────────── минуты (0 - 59)
# │ ┌───────────── часы (0 - 23)
# │ │ ┌───────────── день месяца (1 - 31)
# │ │ │ ┌───────────── месяц (1 - 12)
# │ │ │ │ ┌───────────── день недели (0 - 6) (воскресенье - суббота)
# │ │ │ │ │                                   ИЛИ sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

Например, 0 3 * * 1 означает, что задача запускается еженедельно по понедельникам в 3 часа ночи.

Формат также поддерживает расширенные шаги "Vixie cron". Как объясняется в руководстве FreeBSD:

Значения шага можно использовать вместе с диапазонами. Следование за диапазоном с /<число> указывает пропуски на указанное число в диапазоне. Например, 0-23/2 можно использовать в поле часов для запуска команды через час через час (альтернатива в стандарте V7 — 0,2,4,6,8,10,12,14,16,18,20,22). Шаги также разрешены после звёздочки, так что если нужно "каждые два часа", просто используйте */2.

Вопросительный знак (?) в расписании имеет то же значение, что и звёздочка *, то есть означает любое доступное значение для данного поля.

Кроме стандартного синтаксиса, можно использовать некоторые макросы, например @monthly:

#timeZone

Если для ScheduledTrigger не указан часовой пояс, контроллер интерпретирует расписание относительно своего локального часового пояса.

Вы можете указать часовой пояс для ScheduledTrigger, задав .spec.timeZone в имя валидного часового пояса. Например, установка .spec.timeZone: "Etc/UTC" указывает интерпретировать расписание относительно Всемирного координированного времени.

В бинарных файлах включена база часовых поясов из стандартной библиотеки Go, которая используется как резервная, если внешняя база недоступна в системе.

#params

Список ключ/значение, передаваемый в TriggerTemplate. Они ведут себя точно так же, как параметры Tekton Trigger, поэтому каждую запись можно использовать внутри шаблона через $(tt.params.<name>). Комбинируйте статические значения с контекстными плейсхолдерами для самодокументируемых запусков.

#Контекстные плейсхолдеры

Вы можете использовать следующие контекстные плейсхолдеры в spec.params:

• $(context.date) → YYYY-MM-DD
• $(context.datetime) → метка времени RFC3339, например 2006-01-02T15:04:05Z

Используйте их для согласованных меток, имён артефактов или разбиения по датам независимо от того, когда контроллер фактически обрабатывает событие.

#triggerTemplate

Либо ссылка на переиспользуемый TriggerTemplate (ref), либо встроенный полный шаблон (spec). Используйте ссылки, когда несколько ScheduledTriggers должны разделять одинаковое поведение; используйте встроенные спецификации для автономных задач или когда хотите всю конфигурацию в одном манифесте.

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

• TriggerTemplate Documentation
• CronJob