#ScheduledTrigger

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

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

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

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

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

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

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

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

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

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

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

1. Ночные регрессионные тесты или сканирования безопасности, которые должны запускаться даже при отсутствии активности в Git.
2. Рабочие процессы обслуживания, такие как очистка кэша, ротация артефактов или экспорт баз данных.
3. Задачи соответствия и аудита, которые должны запускаться по фиксированному календарному расписанию.
4. Гибридная автоматизация, где пайплайны, запускаемые webhook-ами, дополняются периодическими базовыми запусками.
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). Используйте ссылки, когда несколько ScheduledTrigger должны использовать одинаковое поведение; используйте встроенные спецификации для автономных задач или когда хотите всю конфигурацию в одном манифесте.

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

• Документация TriggerTemplate
• CronJob