• Русский
  • Входящие webhooks

    Входящие webhooks позволяют запускать pipeline напрямую через HTTP POST-запросы, без необходимости наличия Git-событий.

    Обзор

    Входящие webhooks предоставляют способ:

    • Запускать pipeline из внешних систем
    • Интегрироваться с инструментами CI/CD, которые не используют Git
    • Запускать pipeline вручную или через вызовы API
    • Поддерживать пользовательские payload и параметры
    Как работают входящие webhooks
    1. HTTP POST-запрос: отправьте POST-запрос на конечную точку PAC controller /incoming
    2. Аутентификация: PAC проверяет запрос с использованием secret (из заголовка или параметра query)
    3. Поиск Repository: PAC находит Repository CR на основе имени repository и namespace
    4. Триггер pipeline: PAC обрабатывает payload и запускает соответствующие pipeline, аналогично событиям Git webhook
    5. Создание PipelineRun: PAC создает PipelineRun на основе payload и определений pipeline

    Ключевые отличия от Git webhooks:

    • Не используется Git provider — прямые HTTP-запросы
    • Пользовательский формат payload — вы контролируете структуру
    • Можно запускать pipeline без фактических Git-коммитов
    • Полезно для внешних интеграций и ручных запусков

    Настройка входящего webhook

    1. Включите в Repository CR: добавьте конфигурацию входящего webhook в ваш Repository CR:

      apiVersion: pipelinesascode.tekton.dev/v1alpha1
      kind: Repository
      metadata:
        name: my-repo
        namespace: project-pipelines
      spec:
        url: "https://gitlab.com/user/repo"
        git_provider:
          type: gitlab
          url: "https://gitlab.com"
          secret:
            name: gitlab-secret
            key: token
          webhook_secret:
            name: webhook-secret
            key: secret
        # Incoming webhook configuration
        incoming:
        - type: webhook-url
          secret:
            name: incoming-webhook-secret
            key: secret
    2. Создайте secret для входящего webhook:

      kubectl create secret generic incoming-webhook-secret \
        --from-literal=secret=your-incoming-webhook-secret \
        -n project-pipelines
    3. Получите URL входящего webhook:

    Конечная точка входящего webhook:

    http://<pac-controller-url>/incoming

    Параметры URL (необязательно, также могут передаваться через заголовки):

    • repository: имя Repository CR
    • namespace: namespace, где расположен Repository CR
    • secret: значение secret входящего webhook

    Пример с query-параметрами:

    http://pac.example.com/incoming?repository=my-repo&namespace=project-pipelines&secret=your-secret

    Пример с заголовками (рекомендуется для повышения безопасности):

    http://pac.example.com/incoming

    С заголовками: X-Repository, X-Namespace, X-Secret

    Рекомендуемая практика безопасности

    Используйте заголовки (X-Repository, X-Namespace, X-Secret) вместо query-параметров, чтобы не раскрывать secret в URL и журналах.

    Запуск Pipeline через входящий webhook

    Отправьте POST-запрос на конечную точку входящего webhook:

    curl -X POST \
      http://pac.example.com/incoming \
      -H "Content-Type: application/json" \
      -H "X-Repository: my-repo" \
      -H "X-Namespace: project-pipelines" \
      -H "X-Secret: your-incoming-webhook-secret" \
      -d '{
    "ref": "refs/heads/main",
    "sha": "abc123def456...",
    "repository": {
      "url": "https://gitlab.com/user/repo"
    }
      }'

    Payload входящего webhook

    Входящий webhook принимает JSON payload со следующей структурой:

    {
      "ref": "refs/heads/main",
      "sha": "commit-sha",
      "repository": {
        "url": "https://gitlab.com/user/repo",
        "name": "repo-name",
        "full_name": "user/repo"
      },
      "sender": {
        "login": "username"
      },
      "head_commit": {
        "message": "Commit message",
        "author": {
          "name": "Author Name",
          "email": "author@example.com"
        }
      }
    }

    Пользовательские параметры

    Вы можете передавать пользовательские параметры в payload webhook:

    {
      "ref": "refs/heads/main",
      "sha": "abc123...",
      "repository": {
        "url": "https://gitlab.com/user/repo"
      },
      "params": {
        "environment": "production",
        "deploy": "true"
      }
    }

    Эти параметры будут доступны в вашем pipeline как $(params.environment) и $(params.deploy).

    Вопросы безопасности

    1. Используйте secret: всегда используйте secret webhook для проверки запросов
    2. HTTPS: используйте HTTPS для конечных точек webhook в production
    3. Сетевые политики: ограничьте доступ к конечным точкам входящего webhook
    4. Ограничение скорости: реализуйте rate limiting, чтобы предотвратить злоупотребления
    5. Проверяйте payload: проверяйте входящие payload перед обработкой

    Устранение неполадок во входящих webhooks

    1. Проверьте URL webhook: убедитесь, что URL корректен и доступен

    2. Проверьте secret: убедитесь, что secret совпадает как в запросе, так и в Repository CR

    3. Проверьте логи PAC:

      kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=100 | grep incoming  # Replace <pac-namespace> with your actual namespace (default: tekton-pipelines)
    4. Проверьте Repository CR: убедитесь, что входящий webhook настроен корректно

    5. Проверьте с помощью curl: используйте curl для проверки конечной точки webhook

    Рекомендации

    1. Управление PipelineRun

    • Задайте ограничения на очистку: используйте max-keep-runs, чтобы предотвратить накопление
    • Следите за ресурсами: контролируйте использование ресурсов PipelineRun
    • Архивируйте важные запуски: экспортируйте важные PipelineRun перед очисткой

    2. Мониторинг

    • Используйте labels: назначайте PipelineRun labels для более удобной фильтрации
    • Настройте alerts: настройте alerts для неудачных PipelineRun
    • Регулярная проверка: периодически проверяйте статус и логи PipelineRun

    3. Входящие webhooks

    • Защищайте конечные точки: всегда используйте HTTPS и secret
    • Проверяйте payload: проверяйте входящие payload webhook
    • Документируйте использование: документируйте конечные точки webhook и форматы payload
    • Тщательно тестируйте: тестируйте триггеры webhook перед использованием в production

    Устранение неполадок

    PipelineRun не создан

    1. Проверьте webhook: убедитесь, что webhook настроен и получает события
    2. Проверьте Repository CR: убедитесь, что Repository CR настроен правильно
    3. Проверьте логи PAC: просмотрите логи PAC controller на наличие ошибок
    4. Проверьте файл pipeline: убедитесь, что файл с определением pipeline существует в repository

    PipelineRun не запускается

    1. Проверьте статус: просмотрите статус и conditions PipelineRun
    2. Проверьте логи: изучите логи PipelineRun и TaskRun
    3. Проверьте ресурсы: убедитесь, что в cluster достаточно ресурсов
    4. Проверьте permissions: убедитесь, что ServiceAccount имеет необходимые permissions

    Статус не сообщается

    1. Проверьте token Git provider: убедитесь, что token имеет необходимые scopes
    2. Проверьте PAC Watcher: убедитесь, что PAC Watcher запущен
    3. Проверьте логи: проверьте логи PAC Watcher на наличие ошибок
    4. Проверьте подключение: убедитесь, что PAC может обратиться к API Git provider

    Дальнейшие шаги