#Управление компонентом PAC

В этом руководстве объясняется, как развернуть, обновить и удалить компонент Pipelines-as-Code (PAC) на платформах Kubernetes.

#Предварительные требования

Перед управлением PAC убедитесь, что у вас есть:

• Kubernetes кластер (версия 1.24 или выше)
• Установленный и запущенный Tekton Operator
• Права администратора кластера
• Установленный и настроенный kubectl для доступа к вашему кластеру

#Развертывание компонента PAC

PAC разворачивается путем прямого создания CR OpenShiftPipelinesAsCode. Оператор автоматически создаст и будет управлять всеми необходимыми ресурсами для PAC.

#Развертывание компонента PAC

#Шаг 1: Создайте CR OpenShiftPipelinesAsCode

Создайте YAML-файл с именем pac.yaml:

apiVersion: operator.tekton.dev/v1alpha1
kind: OpenShiftPipelinesAsCode
metadata:
  name: pipelines-as-code
spec:
  settings:
    application-name: Pipelines as Code CI
    hub-url: http://tekton-hub-api.tekton-pipelines:8000/v1
    remote-tasks: "true"
    secret-auto-create: "true"
  targetNamespace: tekton-pipelines  # Пространство имён по умолчанию, можно изменить

Важно:

• Имя ресурса должно быть pipelines-as-code, иначе оператор не развернет компонент PAC.
• Поле targetNamespace указывает, в каком пространстве имён будут развернуты компоненты PAC. По умолчанию — tekton-pipelines, но можно использовать любое другое имя.

Создайте пространство имён, если оно не существует:

kubectl create namespace tekton-pipelines  # Или ваше пользовательское пространство имён

#Шаг 2: Примените конфигурацию

Примените CR в ваш кластер:

kubectl apply -f pac.yaml

Пример вывода:

openshiftpipelinesascode.operator.tekton.dev/pipelines-as-code created

#Шаг 3: Проверьте развертывание

Проверьте статус CR OpenShiftPipelinesAsCode:

kubectl get openshiftpipelinesascodes.operator.tekton.dev

Вывод должен показать CR со статусом Ready:

NAME                  VERSION   READY   REASON
pipelines-as-code    0.x.x     True    Ready

Проверьте статус TektonInstallerSet (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

kubectl get tektoninstallersets -n <pac-namespace> | grep pipelinesascode

Пример вывода:

NAME                              READY   REASON
pipelinesascode-installer-set     True    Ready

Пример вывода:

NAME                              AGE
pipelines-as-code-installer-set   5m

Проверьте, что поды PAC запущены:

kubectl get pods -n <pac-namespace> | grep pipelines-as-code

Пример вывода:

NAME                                      READY   STATUS    RESTARTS   AGE
pipelines-as-code-controller-xxxxx        1/1     Running   0          5m
pipelines-as-code-watcher-xxxxx          1/1     Running   0          5m
pipelines-as-code-webhook-xxxxx          1/1     Running   0          5m

Примечание: В этом документе <pac-namespace> или tekton-pipelines обозначает пространство имён, в котором развернут PAC. Замените его на ваше фактическое имя пространства, если оно отличается.

Вы должны увидеть три пода в состоянии Running:

• pipelines-as-code-controller-*
• pipelines-as-code-watcher-*
• pipelines-as-code-webhook-*

#Настройка доступа

Компонент PAC должен быть доступен извне, чтобы события webhook от Git-провайдеров могли достигать его. URL контроллера PAC используется при настройке вебхуков в вашем Git-провайдере.

Важно: Перед настройкой репозиториев необходимо открыть доступ к контроллеру PAC одним из описанных ниже способов. Команда tkn pac create repo может автоматически определить URL контроллера, если он открыт через Ingress, но его нужно сначала настроить.

Вы можете использовать один из следующих способов для открытия доступа к контроллеру PAC:

#Использование Ingress (HTTP)

Создайте ресурс Ingress (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: <pac-namespace>  # По умолчанию: tekton-pipelines
spec:
  rules:
  - host: pac.example.com
    http:
      paths:
      - backend:
          service:
            name: pipelines-as-code-controller
            port:
              number: 8080
        path: /
        pathType: Prefix

Примените Ingress:

kubectl apply -f ingress.yaml

Пример вывода:

ingress.networking.k8s.io/pipelines-as-code created

Альтернатива: Ingress без доменного имени (без host)

Если у вас нет доменного имени, можно создать Ingress без поля host:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: <pac-namespace>  # По умолчанию: tekton-pipelines
spec:
  rules:
  - http:  # Поле host не указано
      paths:
      - backend:
          service:
            name: pipelines-as-code-controller
            port:
              number: 8080
        path: /
        pathType: Prefix

Затем доступ к PAC осуществляется по IP-адресу Ingress Controller:

# Получить IP Ingress Controller
kubectl get ingress pipelines-as-code -n <pac-namespace>

# Доступ к PAC
# http://<INGRESS-IP>/
# Пример: http://192.168.1.100/

#Использование Ingress (HTTPS)

Сначала создайте TLS Secret (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

apiVersion: v1
kind: Secret
metadata:
  name: pipelines-as-code-tls
  namespace: <pac-namespace>  # По умолчанию: tekton-pipelines
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-tls-certificate>
  tls.key: <base64-encoded-tls-key>

Затем создайте HTTPS Ingress (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: <pac-namespace>  # По умолчанию: tekton-pipelines
spec:
  rules:
  - host: pac.example.com
    http:
      paths:
      - backend:
          service:
            name: pipelines-as-code-controller
            port:
              number: 8080
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - pac.example.com
    secretName: pipelines-as-code-tls

#Использование NodePort

Создайте сервис NodePort (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

apiVersion: v1
kind: Service
metadata:
  name: pipelines-as-code-controller-nodeport
  namespace: <pac-namespace>  # По умолчанию: tekton-pipelines
spec:
  ports:
    - name: http-listener
      port: 8080
      protocol: TCP
      targetPort: 8082  # Контроллер PAC слушает порт 8082
      nodePort: 30080  # Опционально: указать фиксированный NodePort
  selector:
    app.kubernetes.io/part-of: pipelines-as-code
    app.kubernetes.io/component: controller
  type: NodePort

Важно:

• targetPort должен быть 8082 — порт, на котором под контроллера PAC принимает события webhook
• port (8080) — порт сервиса для внутреннего общения в кластере
• nodePort (30080) — внешний порт, доступный извне кластера
• Для Ingress порт сервиса 8080 маршрутизируется на порт 8082 контроллера внутри кластера

Получите NodePort (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

kubectl get service -n <pac-namespace> pipelines-as-code-controller-nodeport -o jsonpath='{.spec.ports[?(@.name=="http-listener")].nodePort}'

Пример вывода:

30080

Доступ к PAC осуществляется по адресу http://<node-ip>:<node-port>.

#Как получить URL контроллера PAC

После открытия доступа к контроллеру PAC вы можете получить URL следующими способами:

#При использовании Ingress

Получите хост Ingress (замените <pac-namespace> на ваше пространство имён PAC, по умолчанию tekton-pipelines):

kubectl get ingress pipelines-as-code -n <pac-namespace> -o jsonpath='{.spec.rules[0].host}'

Пример вывода:

pac.example.com

URL контроллера будет:

• HTTP: http://<ingress-host>
• HTTPS: https://<ingress-host>

#При использовании NodePort

Получите NodePort и IP ноды:

# Установите пространство имён PAC (по умолчанию: tekton-pipelines)
PAC_NAMESPACE="tekton-pipelines"

# Получите NodePort
NODEPORT=$(kubectl get service -n ${PAC_NAMESPACE} pipelines-as-code-controller-nodeport -o jsonpath='{.spec.ports[?(@.name=="http-listener")].nodePort}')

# Получите IP ноды (используется внутренний IP первой ноды)
NODE_IP=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}')

echo "PAC Controller URL: http://${NODE_IP}:${NODEPORT}"

Пример вывода:

PAC Controller URL: http://192.168.1.100:30080

#Автоматическое определение через tkn pac

При использовании tkn pac create repo CLI автоматически определяет URL контроллера, проверяя:

1. Наличие Ingress ресурсов, указывающих на сервис контроллера PAC
2. Наличие сервисов типа LoadBalancer
3. Наличие сервисов типа NodePort
4. Если ничего не найдено, CLI запросит ввод URL вручную

Если автоматическое определение не удалось, вы можете вручную ввести URL контроллера при запросе.

Примечание: URL контроллера должен быть доступен с серверов Git-провайдера для получения событий webhook.

#Настройки конфигурации

Вы можете настроить поведение PAC через поле settings в CR OpenShiftPipelinesAsCode:

Примечание по hub-url:

• Значение по умолчанию указывает на внутренний сервис Tekton Hub в пространстве имён по умолчанию (tekton-pipelines)
• Формат: http://<service-name>.<namespace>:<port>/v1
• Если Tekton Hub развернут в другом пространстве имён, измените namespace в URL соответственно
• Namespace в hub-url — это пространство, где развернут Tekton Hub, оно может отличаться от пространства PAC (targetNamespace)
• Для использования внешнего Hub (например, публичного Tekton Hub) установите https://api.hub.tekton.dev/v1
• Только контроллер PAC нуждается в доступе к этому URL

Примечание по custom-console-name и custom-console-url:

• Эти настройки используются для конфигурации кастомных ссылок на консоль в UI Git-провайдера
• custom-console-name — отображаемое имя для кастомных ссылок
• custom-console-url — базовый URL кастомной консоли (например, Devops Console)
• custom-console-url-pr-details — шаблон URL для страницы деталей PR/MR. Поддерживает переменные: {{namespace}}, {{pipelinerun}}
• custom-console-url-pr-tasklog — шаблон URL для страницы логов задач PR/MR. Поддерживает переменные: {{namespace}}, {{pipelinerun}}, {{taskrun}}
• custom-console-url-namespace — шаблон URL для страницы пространства имён. Поддерживает переменную: {{namespace}}
• Это позволяет настроить ссылки в UI Git-провайдера, чтобы они указывали на Devops Console.

Для получения дополнительной информации о настройках PAC смотрите раздел Common Configuration Updates.

#Обновление компонента PAC

#Обновление конфигурации

1. Отредактируйте CR OpenShiftPipelinesAsCode:

   kubectl edit openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code

2. Обновите поле settings по необходимости:

   spec:
     settings:
       application-name: "My Custom PAC"
       hub-url: http://tekton-hub-api.tekton-pipelines:8000/v1
       remote-tasks: "true"
       error-detection-from-container-logs: "true"

3. Сохраните и выйдите. Оператор автоматически обновит TektonInstallerSet и применит изменения.

#Обновление версии компонента

Для обновления версии PAC обновите Tekton Operator:

1. Обновите Tekton Operator до нужной версии
2. Оператор автоматически:
   • Удалит старый TektonInstallerSet
   • Создаст новый TektonInstallerSet с новой версией PAC
   • Обновит CR OpenShiftPipelinesAsCode с новой версией

Проверьте версию после обновления:

kubectl get openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code -o jsonpath='{.status.version}'

#Проверка обновлений

После обновления конфигурации:

1. Проверьте статус CR OpenShiftPipelinesAsCode:

   kubectl get openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code

Пример вывода:

NAME                VERSION           READY   REASON
pipelines-as-code   v0.36.0-2881c2a   True    

2. Проверьте, не перезапускаются ли поды (замените <pac-namespace> на ваше пространство имён):

   kubectl get pods -n <pac-namespace> | grep pipelines-as-code

Пример вывода:

pipelines-as-code-controller-665b9588c8-q7ftg        1/1     Running   0          4d2h
pipelines-as-code-watcher-86d58cb688-xkzxg           1/1     Running   0          4d2h
pipelines-as-code-webhook-6f6b79c7b6-w8shs           1/1     Running   0          4d2h

3. Проверьте логи подов на наличие ошибок:

   kubectl logs -n <pac-namespace> -l app.kubernetes.io/part-of=pipelines-as-code --tail=50

Пример вывода:

{"level":"info","ts":"2025-11-27T19:28:35.773Z","logger":"pipelinesascode","caller":"adapter/adapter.go:84","msg":"Starting Pipelines as Code version: nightly-20251126-"}
{"level":"info","ts":"2025-11-27T19:28:35.774Z","logger":"pipelinesascode","caller":"injection/health_check.go:43","msg":"Probes server listening on port 8080"}
...

4. Проверьте, что конфигурация применена:

   kubectl get configmap -n <pac-namespace> pipelines-as-code -o yaml

Пример вывода:

apiVersion: v1
kind: ConfigMap
metadata:
  name: pipelines-as-code
  namespace: <pac-namespace>
data:
  application-name: Pipelines as Code CI
  hub-url: https://api.hub.tekton.dev/v1
  remote-tasks: "true"
  secret-auto-create: "true"
  error-detection-from-container-logs: "true"
  error-log-snippet: "true"
  ...

#Откат конфигурации

Если необходимо откатить изменение конфигурации:

1. Восстановите предыдущую конфигурацию в CR OpenShiftPipelinesAsCode:

   kubectl edit openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code

2. Или восстановите из резервной копии:

Создайте резервную копию перед изменениями:

kubectl get openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code -o yaml > pac-backup.yaml

Восстановите из резервной копии:

kubectl apply -f pac-backup.yaml

#Частые обновления конфигурации

#Изменение имени приложения

spec:
  settings:
    application-name: "Новое имя приложения"

#Включение обнаружения ошибок

spec:
  settings:
    error-detection-from-container-logs: "true"
    error-detection-max-number-of-lines: "100"

#Обновление URL Hub

Если Tekton Hub развернут в другом пространстве имён или вы хотите использовать внешний Hub:

spec:
  settings:
    # Для внутреннего Hub в другом пространстве имён
    hub-url: "http://tekton-hub-api.<your-namespace>:8000/v1"
    
    # Или для внешнего/публичного Hub
    hub-url: "https://api.hub.tekton.dev/v1"

Для поиска сервиса Tekton Hub:

kubectl get svc -A | grep tekton-hub-api

Пример вывода:

tekton-pipelines   tekton-hub-api   ClusterIP   10.96.123.45   <none>   8000/TCP   10m

#Отключение удалённых задач

spec:
  settings:
    remote-tasks: "false"

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

Для интеграции PAC с вашей кастомной консолью настройте ссылки. Это позволит отображать ссылки на статус пайплайнов в UI Git-провайдеров (GitLab, GitHub и др.), указывающие на вашу консоль.

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

spec:
  settings:
    # Отображаемое имя кастомной консоли
    custom-console-name: "My Console"
    
    # Базовый URL кастомной консоли (точка входа)
    custom-console-url: "https://console.example.com"
    
    # Шаблон URL для страницы деталей PipelineRun
    # Формат: /console-acp/workspace/{{ namespace }}~CLUSTER_NAME~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}
    # Замените CLUSTER_NAME на имя вашего кластера (например, my-cluster, business-1)
    custom-console-url-pr-details: "https://console.example.com/console-acp/workspace/{{ namespace }}~my-cluster~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}"
    
    # Шаблон URL для страницы логов TaskRun
    # Формат: /console-acp/workspace/~CLUSTER_NAME~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}?tab=task_overview&id={{ task }}
    custom-console-url-pr-tasklog: "https://console.example.com/console-acp/workspace/{{ namespace }}~my-cluster~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}?tab=task_overview&id={{ task }}"
    
    # Шаблон URL для страницы списка пайплайнов пространства имён
    # Формат: /console-acp/workspace/~CLUSTER_NAME~{{ namespace }}/pipeline/pipelineRuns
    custom-console-url-namespace: "https://console.example.com/console-acp/workspace/{{ namespace }}~my-cluster~{{ namespace }}/pipeline/pipelineRuns"

#Как настроить

Шаг 1: Определите имя вашего кластера

Обратитесь к администратору кластера, чтобы узнать правильное имя. Распространённые примеры:

• my-cluster — общее имя кластера
• business-1 — для бизнес-кластера 1
• dev-cluster — для кластера разработки

Имя кластера появляется в URL как ~CLUSTER_NAME~ (обратите внимание на символы тильды).

Шаг 2: Укажите URL консоли

Установите custom-console-url на точку входа вашей консоли (без завершающего слеша):

• https://console.example.com
• https://devops.example.com

Шаг 3: Настройте шаблоны URL

Замените CLUSTER_NAME в шаблонах URL на имя вашего кластера. PAC автоматически заменит следующие переменные:

• {{ namespace }}: пространство имён, в котором выполняется PipelineRun
• {{ pr }}: имя PipelineRun
• {{ task }}: имя задачи в PipelineRun

#Пример: Полная конфигурация

Для кластера с именем my-cluster и консоли по адресу https://console.example.com:

spec:
  settings:
    custom-console-name: "My Console"
    custom-console-url: "https://console.example.com"
    custom-console-url-pr-details: "https://console.example.com/console-acp/workspace/{{ namespace }}~my-cluster~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}"
    custom-console-url-pr-tasklog: "https://console.example.com/console-acp/workspace/{{ namespace }}~my-cluster~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}?tab=task_overview&id={{ task }}"
    custom-console-url-namespace: "https://console.example.com/console-acp/workspace/{{ namespace }}~my-cluster~{{ namespace }}/pipeline/pipelineRuns"

#Пример: Сгенерированные ссылки

Когда PAC создаёт PipelineRun с именем my-app-build-abc123 и задачей build-task в пространстве имён my-project:

• Детали PipelineRun:

  https://console.example.com/console-acp/workspace/my-project~my-cluster~my-project/pipeline/pipelineRuns/detail/my-app-build-abc123

• Логи TaskRun:

  https://console.example.com/console-acp/workspace/my-project~my-cluster~my-project/pipeline/pipelineRuns/detail/my-app-build-abc123?tab=task_overview&id=build-task

• Список пайплайнов пространства имён:

  https://console.example.com/console-acp/workspace/my-project~my-cluster~my-project/pipeline/pipelineRuns

Эти ссылки будут отображаться в UI вашего Git-провайдера (слияния GitLab, pull requests GitHub и др.), позволяя разработчикам быстро переходить в вашу кастомную консоль.

#Удаление компонента PAC

#Удаление CR OpenShiftPipelinesAsCode

#Шаг 1: Удалите CR

kubectl delete openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code

Пример вывода:

openshiftpipelinesascode.operator.tekton.dev "pipelines-as-code" deleted

Оператор автоматически:

• Удалит TektonInstallerSet (внутренний ресурс оператора)
• Удалит все ресурсы, связанные с PAC (Deployments, Services, ConfigMaps и др.)
• Очистит RBAC ресурсы

Примечание: TektonInstallerSet — внутренний ресурс оператора. Не удаляйте его вручную. Оператор управляет его жизненным циклом автоматически.

#Шаг 2: Проверьте удаление

Проверьте, что CR OpenShiftPipelinesAsCode удалён:

kubectl get openshiftpipelinesascodes.operator.tekton.dev

Проверьте, что TektonInstallerSet удалён (замените <pac-namespace> на ваше пространство имён PAC):

kubectl get tektoninstallersets -n <pac-namespace> | grep pipelinesascode

Примечание: Это проверка только для чтения, чтобы убедиться, что внутренний ресурс оператора очищен. Не пытайтесь удалять TektonInstallerSet вручную.

Пример вывода (должен быть пустым, если удаление прошло успешно):

No resources found

Проверьте, что поды PAC завершены:

kubectl get pods -n <pac-namespace> | grep pipelines-as-code

Пример вывода (должен быть пустым, если удаление прошло успешно):

No resources found

#Очистка дополнительных ресурсов

После удаления PAC вы можете очистить дополнительные ресурсы:

#Удаление CR репозиториев

Если у вас есть созданные Repository CR для интеграции с Git-провайдером:

kubectl get repositories -A
kubectl delete repositories --all -n <namespace>

Пример вывода:

repository.pipelinesascode.tekton.dev "my-repo" deleted
repository.pipelinesascode.tekton.dev "another-repo" deleted

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

Важно: При удалении CR OpenShiftPipelinesAsCode оператор автоматически очищает секреты с меткой app.kubernetes.io/part-of=pipelines-as-code в пространстве имён PAC. Однако секреты, связанные с Repository CR, созданные для аутентификации Git-провайдера, нужно удалять вручную.

Секреты, которые очищаются автоматически (в пространстве имён PAC):

• pipelines-as-code-secret — внутренний секрет контроллера PAC (с меткой app.kubernetes.io/part-of=pipelines-as-code)

Секреты, требующие ручной очистки (в пространствах имён Repository CR):

• gitlab-secret / github-secret — токены доступа Git-провайдера
• webhook-secret — секреты для проверки webhook
• git-auth-secret — токены доступа к приватным репозиториям
• git-ssh-secret — SSH-ключи для доступа к репозиториям

Чтобы найти и удалить секреты, связанные с Repository CR:

1. Список всех секретов в пространстве имён, где расположены Repository CR:

   kubectl get secrets -n <namespace>

2. Определите секреты, созданные вами для PAC Repository CR.

   Примечание: Имена секретов могут отличаться в зависимости от способа создания. Внимательно просмотрите список, чтобы определить связанные с PAC секреты.

3. Перед удалением убедитесь, что:

   • Все Repository CR, использующие секрет, удалены
   • Секрет не используется другими приложениями или ресурсами в кластере
   • Вы уверены, что секрет можно безопасно удалить

4. Удалите секрет только если уверены, что он больше не нужен:

   kubectl delete secret <secret-name> -n <namespace>

Предупреждение:

• Секреты могут использоваться несколькими Repository CR или другими ресурсами
• Удаление используемого секрета приведёт к сбоям аутентификации
• Всегда проверяйте, что секрет не используется, перед удалением

Пример вывода:

secret "gitlab-secret" deleted

#Удаление Ingress/Service

Если вы создавали Ingress или сервис NodePort для PAC (замените <pac-namespace> на ваше пространство имён PAC):

kubectl delete ingress pipelines-as-code -n <pac-namespace>
kubectl delete service pipelines-as-code-controller-nodeport -n <pac-namespace>

Пример вывода:

ingress.networking.k8s.io "pipelines-as-code" deleted
service "pipelines-as-code-controller-nodeport" deleted

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

#Поды PAC не запускаются

Проверьте логи подов (замените <pac-namespace> на ваше пространство имён PAC):

kubectl logs -n <pac-namespace> -l app.kubernetes.io/part-of=pipelines-as-code

Пример вывода (пример записей логов):

{"level":"info","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Starting PAC controller"}
{"level":"info","ts":"2024-01-01T12:00:01Z","logger":"controller","msg":"PAC controller ready"}

#CR OpenShiftPipelinesAsCode не готов

Проверьте статус CR и события:

kubectl describe openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code

Пример вывода (сокращённый):

Name:         pipelines-as-code
Namespace:    
Status:       Ready
Version:      0.x.x
Events:
  Type    Reason   Age   From              Message
  ----    ------   ----  ----              -------
  Normal  Ready    5m    tekton-operator   PAC component deployed successfully

#Проблемы с TektonInstallerSet

Важно: TektonInstallerSet — внутренний ресурс оператора. При проблемах с ним не изменяйте и не удаляйте его напрямую. Решайте проблемы через CR OpenShiftPipelinesAsCode.

Проверьте статус TektonInstallerSet для диагностики (замените <pac-namespace> на ваше пространство имён PAC):

kubectl get tektoninstallersets -n <pac-namespace> -o yaml

Если TektonInstallerSet показывает ошибки:

1. Проверьте статус CR OpenShiftPipelinesAsCode на наличие проблем
2. Просмотрите логи оператора для подробных сообщений об ошибках
3. При необходимости удалите и создайте заново CR OpenShiftPipelinesAsCode (оператор автоматически пересоздаст TektonInstallerSet)

Пример вывода (сокращённый):

apiVersion: tekton.dev/v1alpha1
kind: TektonInstallerSet
metadata:
  name: pipelines-as-code-installer-set
  namespace: tekton-pipelines
status:
  conditions:
  - status: "True"
    type: Ready

#CR не удаляется

Если CR OpenShiftPipelinesAsCode не удаляется, проверьте наличие finalizers:

kubectl get openshiftpipelinesascodes.operator.tekton.dev pipelines-as-code -o yaml | grep finalizers

Пример вывода (если finalizers есть):

  finalizers:
  - tekton.dev/operator

Если finalizers отсутствуют, вывод будет пустым, что означает, что CR можно удалить.

Если finalizers есть, оператор может ещё обрабатывать удаление. Подождите несколько минут и попробуйте снова.

#Ресурсы не удаляются

Если некоторые ресурсы не удаляются автоматически:

1. Проверьте статус TektonInstallerSet для диагностики (замените <pac-namespace> на ваше пространство имён PAC):

   kubectl get tektoninstallersets -n <pac-namespace> -o yaml

   Примечание: Это проверка только для чтения. TektonInstallerSet — внутренний ресурс оператора. Не удаляйте его вручную.

2. Удалите оставшиеся ресурсы вручную:

   kubectl delete deployment -n <pac-namespace> -l app.kubernetes.io/part-of=pipelines-as-code
   kubectl delete service -n <pac-namespace> -l app.kubernetes.io/part-of=pipelines-as-code

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

• Configure Repository
• Maintain Pipeline Code
• Trigger Pipelines