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

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

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

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

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

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

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

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

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

.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. Эти аннотации добавляются в metadata 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)

Примечание: При использовании регулярных выражений в 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 становится телом комментария, а не исходным payload pull request
• Чтобы повторно запустить Pull Request при использовании CEL на теле payload, сделайте фиктивное обновление, изменив коммит и сделав форсированный push: git commit --amend --no-edit && git push --force-with-lease

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

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

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

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

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

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 автоматически создаёт этот секрет при настройке аутентификации для приватного репозитория (см. Configure Authentication for Private Repositories). Формат имени секрета: pac-gitauth-<repository-name>-<hash>.

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

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

#Использование аннотаций 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 — Руководство по устранению неполадок