#Поддержка кода Pipeline

В этом руководстве объясняется, как поддерживать определения pipeline в вашем репозитории исходного кода с помощью PAC.

#Расположение файлов Pipeline

PAC ищет определения pipeline в определённых местах внутри вашего репозитория:

#Расположение по умолчанию

Расположение по умолчанию — .tekton/pipelinerun.yaml в корне вашего репозитория.

your-repo/
├── .tekton/
│   └── pipelinerun.yaml
├── src/
└── README.md

#Несколько файлов Pipeline

Вы можете организовать pipelines в нескольких файлах:

.tekton/
├── pipelinerun.yaml          # Основной pipeline
├── test-pipeline.yaml        # Тестовый pipeline
└── deploy-pipeline.yaml      # Pipeline для деплоя

PAC обработает все файлы с расширениями .yaml и .yml в директории .tekton/.

#Структура определения Pipeline

Pipeline PAC — это стандартный ресурс Tekton PipelineRun с аннотациями, специфичными для PAC.

#Базовая структура

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: my-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
spec:
  pipelineSpec:
    tasks:
    - name: hello
      taskSpec:
        steps:
        - name: echo
          image: alpine:latest
          script: |
            echo "Hello from PAC!"

#Использование существующего Pipeline

Вы можете ссылаться на существующий ресурс Pipeline, уже определённый в вашем Kubernetes кластере:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: my-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
spec:
  pipelineRef:
    name: my-pipeline-resource

#Аннотации событий

PAC использует аннотации для определения момента запуска pipeline. Эти аннотации добавляются в метаданные PipelineRun. Вы можете сопоставлять разные события Git-провайдера с каждым pipeline, используя специальные аннотации. Если несколько pipeline соответствуют событию, Pipelines as Code запускает их параллельно и публикует результаты в Git-провайдер сразу после завершения каждого pipeline.

#Сопоставление события Pull Request с PipelineRun

Вы можете использовать следующий пример для сопоставления pipeline с событием pull_request, нацеленным на ветку main:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: pipeline-pr-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
spec:
  pipelineSpec:
    tasks:
    - name: test
      taskSpec:
        steps:
        - name: test
          image: alpine:latest
          script: |
            echo "Running tests for PR to main"

#Сопоставление события Push с PipelineRun

Вы можете использовать следующий пример для сопоставления pipeline с событием push, нацеленным на ветку refs/heads/main:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: pipeline-push-on-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
spec:
  pipelineSpec:
    tasks:
    - name: build
      taskSpec:
        steps:
        - name: build
          image: alpine:latest
          script: |
            echo "Building on push to main"

#Указание веток

Вы можете указать несколько веток, добавляя записи через запятую. Например, "[main, release-nightly]". Кроме того, можно указать:

• Полные ссылки на ветки, например "refs/heads/main"
• Глобальные шаблоны с паттернами, например "refs/heads/*"
• Теги, например "refs/tags/1.*"

Примеры:

Несколько веток:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main, release-nightly]"
    pipelinesascode.tekton.dev/on-event: "[push]"

Все ветки с использованием глоба:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/*]"
    pipelinesascode.tekton.dev/on-event: "[push]"

Паттерн ветки:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/feature/*]"
    pipelinesascode.tekton.dev/on-event: "[push]"

Теги:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/tags/1.*]"
    pipelinesascode.tekton.dev/on-event: "[push]"

Примечание: Аннотации on-target-branch и on-event соответствуют стандартному формату, указанному в официальной документации. Для триггеров на основе комментариев используйте аннотацию pipelinesascode.tekton.dev/on-comment.

#Фильтрация по веткам и путям

#Фильтрация по веткам

Фильтруйте по целевой ветке с помощью аннотации on-target-branch. Можно использовать глобальные шаблоны для сопоставления нескольких веток:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/feature/*]"
    pipelinesascode.tekton.dev/on-event: "[push]"

Фильтрация по нескольким конкретным веткам:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main, develop]"
    pipelinesascode.tekton.dev/on-event: "[push, pull_request]"

#Фильтрация по путям

Чтобы запускать PipelineRun на основе изменений в определённых путях в событии, используйте аннотацию pipelinesascode.tekton.dev/on-path-change.

Можно указать несколько путей, разделённых запятыми. Первый глоб, совпадающий с изменёнными файлами в PR, вызовет запуск PipelineRun. Если нужно сопоставить файл или путь, содержащий запятую, её можно экранировать HTML-сущностью ,.

При этом необходимо указывать тип события и целевую ветку с помощью аннотаций on-target-branch и on-event.

:::important Ограничение аннотации Path Change

Если вы используете выражение CEL (on-cel-expression), аннотации on-path-change и on-path-change-ignore будут игнорироваться. Для фильтрации по путям при использовании CEL применяйте свойства files.* или функцию .pathChanged().

:::

Пример:

metadata:
  name: pipeline-docs-and-manual
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
    pipelinesascode.tekton.dev/on-path-change: "[docs/**.md, manual/**.rst]"

Эта конфигурация сопоставит и запустит PipelineRun, когда событие pull_request нацелено на ветку main и включает изменения файлов с суффиксом .md в директории docs (и её поддиректориях) или файлов с суффиксом .rst в директории manual.

Паттерны путей:

• Используйте glob-шаблоны, а не регулярные выражения
• src/** — соответствует всем файлам в директории src и её поддиректориях
• *.go — соответствует всем Go-файлам в корне репозитория
• Для нескольких паттернов используйте значения через запятую: "[src/**,*.go,config/**]"

Тестирование glob-паттернов: CLI tkn pac предоставляет удобную команду для проверки glob-паттернов:

tkn pac info globbing "[PATTERN]"

#Исключение изменений по путям

Вы можете использовать обратную аннотацию pipelinesascode.tekton.dev/on-path-change-ignore, чтобы запускать PipelineRun, когда указанные пути не изменились.

При этом необходимо указывать тип события и целевую ветку. Если используется выражение CEL, аннотация on-path-change-ignore будет игнорироваться.

Этот PipelineRun запустится, если изменения произошли вне папки docs:

metadata:
  name: pipeline-not-on-docs-change
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
    pipelinesascode.tekton.dev/on-path-change-ignore: "[docs/***]"

#Комбинирование Path Change и Ignore

Вы можете комбинировать аннотации on-path-change и on-path-change-ignore:

metadata:
  name: pipeline-docs-not-generated
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
    pipelinesascode.tekton.dev/on-path-change: "[docs/***]"
    pipelinesascode.tekton.dev/on-path-change-ignore: "[docs/generated/***]"

Эта конфигурация запускает PipelineRun, если есть изменения в директории docs, но нет изменений в docs/generated.

Важно: Аннотация on-path-change-ignore всегда имеет приоритет над on-path-change. Если файл совпадает с обоими паттернами, PipelineRun не будет запущен.

#Расширенное сопоставление событий

Pipelines as Code поддерживает фильтрацию на основе Common Expression Language (CEL) для сложного сопоставления событий.

:::important CEL vs Аннотации

• Если используется on-cel-expression: PAC применяет CEL-выражение и игнорирует аннотации on-target-branch и on-event
• Если on-cel-expression не используется: PAC применяет аннотации on-target-branch и on-event для сопоставления

Нельзя использовать одновременно CEL-выражения и простые аннотации. Выберите подход в зависимости от ваших задач:

• Используйте простые аннотации (on-target-branch, on-event) для базового сопоставления
• Используйте CEL-выражения для сложной фильтрации, отрицаний и продвинутых условий

:::

В отличие от простого сопоставления по аннотации on-target-branch, CEL-выражения позволяют задавать сложные фильтры и отрицания.

#Формат CEL-выражения

Используйте аннотацию pipelinesascode.tekton.dev/on-cel-expression с CEL-выражением:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: cel-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" && target_branch == "main"
spec:
  pipelineSpec:
    tasks:
    - name: test
      taskSpec:
        steps:
        - name: test
          image: alpine:latest
          script: |
            echo "Running tests"

#Доступные поля и функции CEL

#Основные поля

• event: событие push или pull_request
• target_branch: целевая ветка
• source_branch: ветка-источник события pull_request. Для push-событий совпадает с target_branch
• event_title: заголовок события, например, заголовок коммита для push или заголовок pull/merge request для pull_request. В настоящее время поддерживаются GitHub, GitLab и Bitbucket Cloud
• last_commit_title: заголовок последнего коммита в событии (расширение платформы — недоступно в upstream Tekton)

#Поля изменений файлов

Позволяют фильтровать по конкретным изменениям файлов в событии:

• files.all: все изменённые файлы (добавленные, изменённые, удалённые, переименованные)
• files.added: добавленные файлы
• files.deleted: удалённые файлы
• files.modified: изменённые файлы
• files.renamed: переименованные файлы

Примечание: Для pull request в список входят все файлы, относящиеся к PR. Эти свойства доступны для событий push и pull_request.

#Расширенные поля

• body: полный payload от Git-провайдера (Technology Preview)
• headers: HTTP-заголовки от Git-провайдера (в виде map, заголовки всегда в нижнем регистре)

#Функции

• .matches(pattern): сопоставление строки с регулярным выражением
• .pathChanged(): суффиксная функция для строки. Строка может быть glob-шаблоном для проверки изменений пути. В настоящее время поддерживаются только GitHub и GitLab. Внимание: .pathChanged() поддерживает glob, но не различает типы изменений (добавлено, изменено, удалено). Для более точной фильтрации используйте свойства files.*
• .startsWith(prefix): проверка, начинается ли строка с префикса
• .contains(substring): проверка, содержит ли строка подстроку
• .exists(iterator, condition): проверка, существует ли элемент в коллекции, удовлетворяющий условию (используется с files.*)

#Примеры CEL-выражений

#Сопоставление Pull Request из конкретной ветки

Сопоставить событие pull_request, нацеленное на ветку main и исходящее из ветки wip:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      target_branch == "main" &&
      source_branch.startsWith("wip")

#Фильтрация по пути с .pathChanged()

Чтобы запускать pipeline только при изменении пути, используйте .pathChanged() с glob-шаблоном:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      "docs/*.md".pathChanged()

Это сопоставит любые markdown-файлы в директории docs.

#Сопоставление по нескольким паттернам путей

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "push" &&
      ("src/**".pathChanged() || "config/**".pathChanged())

Примечание: .pathChanged() поддерживает glob, но не различает типы изменений. Для более точной фильтрации используйте свойства files.*.

#Сопоставление по заголовку события

Сопоставить все pull request, начинающиеся с заголовка [DOWNSTREAM]:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      event_title.startsWith("[DOWNSTREAM]")

#Исключение ветки

Запускать pipeline на событии pull_request, но пропускать ветку experimental:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      !source_branch.matches("^experimental.*")

#Сложный пример CEL-выражения

Комплексный пример с несколькими условиями:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |-
      (
        source_branch.matches("^(main|master|release-.*)$") ||
        !event_title.contains("Auto-commit")
      ) && ((
        event == "push" && (
          source_branch.matches("^(main|master|release-.*)$") ||
          target_branch.matches("^(main|master|release-.*)$") ||
          target_branch.startsWith("refs/tags/")
        )
      ) || (
        event == "pull_request" && (
          target_branch.matches("^(main|master|release-.*)$")
        )
      ))

Это выражение:

• Сопоставляет события push или pull_request
• Запускается только на ветках main, master или release-* (или тегах)
• Исключает коммиты с "Auto-commit" в заголовке (если не на защищённых ветках)

#Сопоставление PipelineRun по ветке с регулярным выражением

Сопоставить имя ветки с помощью regex. Например, запускать PipelineRun для pull_request, где имя исходной ветки содержит подстроку feat/:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      source_branch.matches(".*feat/.*")

#Сопоставление PipelineRun по изменениям файлов с помощью свойства Files

Можно использовать свойство files для сопоставления конкретных типов изменений файлов. Это мощнее, чем .pathChanged(), так как позволяет фильтровать по типам изменений (добавлено, изменено, удалено, переименовано).

Сопоставить любые изменённые файлы в директории tmp:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      files.all.exists(x, x.matches('tmp/'))

Сопоставить любые добавленные файлы в директориях src или pkg:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      files.added.exists(x, x.matches('src/|pkg/'))

Сопоставить изменённые файлы с именем test.go:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      files.modified.exists(x, x.matches('test.go'))

Доступные свойства файлов:

• files.all: все изменённые файлы (добавленные, изменённые, удалённые, переименованные)
• files.added: добавленные файлы
• files.deleted: удалённые файлы
• files.modified: изменённые файлы
• files.renamed: переименованные файлы

#Фильтрация PipelineRun для исключения изменений, не связанных с кодом

Исключить PipelineRun, если изменены только документация или конфигурационные файлы. Этот пример фильтрует события pull_request, исключая изменения, затрагивающие только документацию, конфигурацию или другие не кодовые файлы:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      target_branch == "main" &&
      !files.all.all(x, x.matches('^docs/') || x.matches('\\.md$') || x.matches('(\\.gitignore|OWNERS|PROJECT|LICENSE)$'))

Это выражение:

• Сопоставляет только события pull_request, нацеленные на ветку main
• Исключает PipelineRun, если все изменённые файлы соответствуют одному из следующих паттернов:
  • Файлы в директории docs/ (^docs/)
  • Markdown-файлы (\\.md$)
  • Общие метаданные репозитория (.gitignore, OWNERS, PROJECT, LICENSE)

Примечание: При использовании regex в CEL-выражениях не забудьте корректно экранировать специальные символы. Обратный слэш (\) нужно удваивать (\\) для правильного экранирования в строковом контексте CEL.

#Сопоставление PipelineRun по заголовку события

Сопоставить pull request или коммиты по заголовку. event_title — это заголовок pull request для событий pull_request и заголовок коммита для событий push:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" &&
      event_title.startsWith("[DOWNSTREAM]")

Сопоставить коммиты, в заголовке которых нет "Auto-commit":

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      event == "push" &&
      !event_title.contains("Auto-commit")

#Сопоставление PipelineRun по телу payload

Тело payload, переданное Git-провайдером, доступно в CEL-переменной body. Вы можете фильтровать по любым данным, которые отправляет Git-провайдер.

Например, на GitHub сопоставить только если pull request нацелен на main, автор — superuser, и действие — synchronize (обновление pull request):

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      body.pull_request.base.ref == "main" &&
      body.pull_request.user.login == "superuser" &&
      body.action == "synchronize"

Важные замечания:

• При сопоставлении по телу payload в Pull Request, GitOps-команды типа /retest не работают корректно, так как тело payload становится телом комментария, а не исходного pull request
• Чтобы повторно запустить Pull Request при использовании CEL по телу payload, сделайте фиктивное обновление, изменив коммит и форсированно запушив: git commit --amend --no-edit && git push --force-with-lease

#Сопоставление PipelineRun по заголовкам запроса

Фильтрация по заголовкам, отправленным Git-провайдером. Заголовки доступны в виде списка и всегда в нижнем регистре.

Сопоставить только GitHub pull_request события по заголовку:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      headers['x-github-event'] == "pull_request"

Сопоставить только GitLab merge request события:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-cel-expression: |
      headers['x-gitlab-event'] == "Merge Request Hook"

#Отмена выполняющихся Pipeline

Аннотация pipelinesascode.tekton.dev/cancel-in-progress позволяет автоматически отменять запущенный pipeline, если запускается новый pipeline того же типа.

#Настройка отмены

Установите аннотацию в "true", чтобы включить автоматическую отмену:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: my-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
    pipelinesascode.tekton.dev/cancel-in-progress: "true"
spec:
  pipelineSpec:
    tasks:
    - name: hello
      taskSpec:
        steps:
        - name: echo
          image: alpine:latest
          script: |
            echo "Hello from PAC!"

Поведение:

• При запуске нового pipeline (например, нового push в ту же ветку) все текущие выполняющиеся pipeline с такой аннотацией автоматически отменяются
• Это полезно для предотвращения одновременного выполнения нескольких pipeline на одной ветке
• Отменённые pipeline будут отображаться со статусом "Cancelled" в Git-провайдере

#Примеры использования

Предотвращение дублирующих запусков на ветке main:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
    pipelinesascode.tekton.dev/cancel-in-progress: "true"

Это гарантирует, что при быстром последовательном пуше в ветку main будет запущен только последний pipeline, что экономит ресурсы.

Использование с Pull Requests:

metadata:
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
    pipelinesascode.tekton.dev/cancel-in-progress: "true"

При обновлении PR новым коммитом текущий pipeline для этого PR будет отменён, и запустится новый.

#Параметризация коммитов и URL

Вы можете задавать параметры коммита и URL, используя динамические переменные в формате {{<var>}}. Эти переменные можно использовать в:

• Значения параметров PipelineRun
• Параметры задач
• Скрипты и команды шагов
• Любые строковые значения в определении pipeline

#Доступные переменные

В настоящее время доступны следующие переменные:

#Примеры использования переменных

#Информация о Git-репозитории

spec:
  params:
  - name: repo-url
    value: "{{ repo_url }}"
  - name: revision
    value: "{{ revision }}"
  - name: branch
    value: "{{ source_branch }}"
  pipelineSpec:
    tasks:
    - name: clone
      taskSpec:
        steps:
        - name: clone
          image: alpine/git:latest
          script: |
            git clone {{ repo_url }}
            cd {{ repo_name }}
            git checkout {{ revision }}

#Информация о событии

spec:
  params:
  - name: sender
    value: "{{ sender }}"
  - name: branch
    value: "{{ target_branch }}"
  pipelineSpec:
    tasks:
    - name: notify
      taskSpec:
        steps:
        - name: notify
          image: alpine:latest
          script: |
            echo "Pipeline triggered by {{ sender }} on branch {{ target_branch }}"

#Информация о Pull Request

spec:
  params:
  - name: pr-number
    value: "{{ pull_request_number }}"
  pipelineSpec:
    tasks:
    - name: test
      taskSpec:
        steps:
        - name: test
          image: alpine:latest
          script: |
            echo "Testing Pull Request #{{ pull_request_number }}"

Примечание: Переменная {{ pull_request_number }} доступна только для событий типа pull_request. Для push-событий эта переменная не заполняется.

#Использование секрета для аутентификации Git

Для приватных репозиториев PAC автоматически создаёт секрет для аутентификации git. Вы можете ссылаться на этот секрет в задачах pipeline:

spec:
  pipelineSpec:
    tasks:
    - name: clone
      taskSpec:
        steps:
        - name: clone
          image: alpine/git:latest
          env:
          - name: GIT_CREDENTIALS
            valueFrom:
              secretKeyRef:
                name: "{{ git_auth_secret }}"
                key: password
          script: |
            git clone https://github.com/user/private-repo

Примечание: Переменная {{ git_auth_secret }} доступна только для приватных репозиториев. PAC автоматически создаёт этот секрет при настройке аутентификации для приватного репозитория (см. Настройка аутентификации для приватных репозиториев). Формат имени секрета: pac-gitauth-<repository-name>-<hash>.

#Разрешение задач (Task Resolution)

PAC может автоматически разрешать задачи из нескольких источников. Вы можете использовать либо аннотации PAC (рекомендуется), либо синтаксис resolver Tekton.

#Использование аннотаций PAC (рекомендуется)

PAC предоставляет аннотации для автоматического получения и встраивания удалённых задач из Tekton Hub. Это проще, чем использовать синтаксис resolver.

#Аннотации для удалённых задач

Ссылайтесь на задачи из Tekton Hub с помощью аннотаций:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: my-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
    pipelinesascode.tekton.dev/task: "git-clone"
    pipelinesascode.tekton.dev/task-1: "golangci-lint"
spec:
  pipelineSpec:
    tasks:
    - name: fetch
      taskRef:
        name: git-clone
      params:
        - name: url
          value: "{{ repo_url }}"
        - name: revision
          value: "{{ revision }}"
    - name: lint
      taskRef:
        name: golangci-lint
      runAfter: [fetch]

Как это работает:

• Аннотация pipelinesascode.tekton.dev/task: "git-clone" указывает PAC получить задачу из Tekton Hub
• Используйте нумерованные аннотации (task-1, task-2 и т.д.) для дополнительных задач
• PAC автоматически встраивает все указанные определения задач в ваш PipelineRun
• Затем вы можете ссылаться на них через taskRef.name с именем задачи из Tekton Hub

Нумерация аннотаций:

• pipelinesascode.tekton.dev/task: первая задача (эквивалент task-0)
• pipelinesascode.tekton.dev/task-1: вторая задача
• pipelinesascode.tekton.dev/task-2: третья задача
• И так далее...

Подробнее см. в PAC Resolver.

#Использование синтаксиса Resolver

Вы также можете использовать синтаксис resolver Tekton для ссылок на задачи.

#Локальные задачи

Ссылайтесь на задачи, определённые в том же репозитории:

.tekton/
├── pipelinerun.yaml
└── tasks/
    └── build-task.yaml

spec:
  pipelineSpec:
    tasks:
    - name: build
      taskRef:
        resolver: git
        params:
        - name: url
          value: "{{ repo_url }}"
        - name: revision
          value: "{{ revision }}"
        - name: pathInRepo
          value: .tekton/tasks/build-task.yaml

#Задачи из Tekton Hub

Ссылайтесь на задачи из Tekton Hub:

spec:
  pipelineSpec:
    tasks:
    - name: git-clone
      taskRef:
        resolver: hub
        params:
        - name: name
          value: git-clone
        - name: kind
          value: task

#Задачи по удалённому URL

Ссылайтесь на задачи по удалённым URL с помощью аннотаций PAC (рекомендуется):

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: my-pipeline
  annotations:
    # PAC автоматически обрабатывает аутентификацию для удалённых задач
    pipelinesascode.tekton.dev/task: "https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.9/git-clone.yaml"
spec:
  pipelineSpec:
    tasks:
    - name: build
      taskRef:
        name: git-clone  # Ссылка на задачу по имени

#Примеры Pipeline

#Простой pipeline сборки

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: build-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
spec:
  pipelineSpec:
    tasks:
    - name: build
      taskSpec:
        steps:
        - name: build
          image: golang:1.21
          script: |
            go build -o app ./cmd/app
            go test ./...

#Тестовый pipeline для PR

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: test-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
spec:
  pipelineSpec:
    tasks:
    - name: test
      taskSpec:
        steps:
        - name: run-tests
          image: golang:1.21
          script: |
            go test -v ./...
            go vet ./...
            go fmt ./...

#Многоступенчатый pipeline

Этот пример демонстрирует полный CI pipeline с этапами clone, test и build на реальном репозитории:

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: ci-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-event: "[push, pull_request]"
spec:
  workspaces:
  - name: source
    emptyDir: {}
  pipelineSpec:
    workspaces:
    - name: source
    tasks:
    - name: clone
      workspaces:
      - name: source
      taskSpec:
        workspaces:
        - name: source
        steps:
        - name: clone
          image: alpine/git:latest
          script: |
            git clone https://github.com/tektoncd/catalog $(workspaces.source.path)
            cd $(workspaces.source.path)
            echo "Cloned repository successfully"
            ls -la
    - name: check-content
      runAfter: [clone]
      workspaces:
      - name: source
      taskSpec:
        workspaces:
        - name: source
        steps:
        - name: check
          image: alpine:latest
          script: |
            cd $(workspaces.source.path)
            echo "Repository structure:"
            ls -la
            echo "Total files:"
            find . -type f | wc -l
    - name: validate-yaml
      runAfter: [check-content]
      workspaces:
      - name: source
      taskSpec:
        workspaces:
        - name: source
        steps:
        - name: validate
          image: alpine:latest
          script: |
            cd $(workspaces.source.path)
            echo "Checking for YAML files"
            find . -name "*.yaml" -o -name "*.yml" | head -10

#Условный pipeline

Используйте разные pipeline в зависимости от ветки:

# .tekton/pipelinerun-main.yaml
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: main-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
spec:
  pipelineSpec:
    tasks:
    - name: deploy
      taskSpec:
        steps:
        - name: deploy
          image: deploy-tool:latest
          script: |
            deploy.sh production

# .tekton/pipelinerun-develop.yaml
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: develop-pipeline
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/develop]"
    pipelinesascode.tekton.dev/on-event: "[push]"
spec:
  pipelineSpec:
    tasks:
    - name: deploy
      taskSpec:
        steps:
        - name: deploy
          image: deploy-tool:latest
          script: |
            deploy.sh staging

#Лучшие практики

#1. Контроль версий

• Храните все определения pipeline в Git
• Проверяйте изменения pipeline через Merge Requests
• Используйте теги версий pipeline для воспроизводимости

#2. Организация

• Используйте описательные имена pipeline
• Группируйте связанные задачи вместе
• Используйте отдельные файлы для разных типов pipeline

#3. Безопасность

• Не храните секреты в файлах pipeline
• Используйте Kubernetes Secrets для чувствительных данных
• Ограничивайте права pipeline с помощью RBAC

#4. Переиспользуемость

• Создавайте переиспользуемые определения задач
• Используйте задачи из Tekton Hub, когда возможно
• Делитесь общими задачами между репозиториями

#5. Тестирование

• Тестируйте изменения pipeline в feature-ветках
• Используйте pipeline для Merge Request для проверки изменений
• Держите pipeline простыми и поддерживаемыми

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

#Pipeline не запускается

1. Проверьте правильность аннотаций:

   cat .tekton/pipelinerun.yaml | grep pipelinesascode.tekton.dev

2. Убедитесь, что имена веток совпадают:

   git branch --show-current

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

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=100  # Замените <pac-namespace> на ваш namespace (по умолчанию: tekton-pipelines)

#Переменные не подставляются

1. Проверьте синтаксис переменных: используйте формат {{ variable_name }}, например {{ revision }} или {{ repo_url }}
2. Проверьте правильность написания имён переменных: имена должны совпадать точно (например, {{ repo_owner }}, {{ source_branch }})
3. Убедитесь в доступности переменных: некоторые, например {{ pull_request_number }}, доступны только для событий pull_request
4. Просмотрите логи контроллера PAC на предмет ошибок разрешения переменных

#Задачи не найдены

1. Проверьте правильность ссылок на задачи
2. Убедитесь, что файлы задач существуют в репозитории
3. Проверьте имена задач в Tekton Hub
4. Проверьте сетевое соединение для удалённых задач

#Следующие шаги

• PAC Resolver — изучите аннотации для удалённых задач и pipeline
• Trigger Pipelines — изучите различные методы триггера
• Configure Repository — руководство по настройке репозитория
• Common Issues — руководство по устранению неполадок