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

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

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

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

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

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

PAC развертывается путем непосредственного создания CR OpenShiftPipelinesAsCode. Operator автоматически создаст и будет управлять всеми необходимыми ресурсами для 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  # Default namespace, you can customize this

Важно:

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

Создайте namespace, если он еще не существует:

kubectl create namespace tekton-pipelines  # Or your custom namespace name

#Шаг 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> на ваш фактический 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

Проверьте, что pod'ы 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 обозначает namespace, в котором развернут PAC. Если у вас используется другое имя namespace, замените его на фактическое.

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

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

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

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

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

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

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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: <pac-namespace>  # Default: 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>  # Default: tekton-pipelines
spec:
  rules:
  - http:  # No host field specified
      paths:
      - backend:
          service:
            name: pipelines-as-code-controller
            port:
              number: 8080
        path: /
        pathType: Prefix

Затем получайте доступ к PAC по IP-адресу Ingress Controller:

# Get Ingress Controller IP
kubectl get ingress pipelines-as-code -n <pac-namespace>

# Access PAC
# http://<INGRESS-IP>/
# Example: http://192.168.1.100/

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

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

apiVersion: v1
kind: Secret
metadata:
  name: pipelines-as-code-tls
  namespace: <pac-namespace>  # Default: tekton-pipelines
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-tls-certificate>
  tls.key: <base64-encoded-tls-key>

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: <pac-namespace>  # Default: 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

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

apiVersion: v1
kind: Service
metadata:
  name: pipelines-as-code-controller-nodeport
  namespace: <pac-namespace>  # Default: tekton-pipelines
spec:
  ports:
    - name: http-listener
      port: 8080
      protocol: TCP
      targetPort: 8082  # PAC controller listens on port 8082
      nodePort: 30080  # Optional: specify a fixed NodePort
  selector:
    app.kubernetes.io/part-of: pipelines-as-code
    app.kubernetes.io/component: controller
  type: NodePort

Важно:

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

Получите NodePort (замените <pac-namespace> на ваш 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

Получите host Ingress (замените <pac-namespace> на ваш 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 узла:

# Set your PAC namespace (default: tekton-pipelines)
PAC_NAMESPACE="tekton-pipelines"

# Get NodePort
NODEPORT=$(kubectl get service -n ${PAC_NAMESPACE} pipelines-as-code-controller-nodeport -o jsonpath='{.spec.ports[?(@.name=="http-listener")].nodePort}')

# Get Node IP (use the first node's internal 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, указывающие на Service контроллера PAC
2. Проверяет Services типа LoadBalancer
3. Проверяет Services типа NodePort
4. Если ничего не найдено, предлагает вручную ввести URL

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

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

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

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

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

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

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

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

Дополнительные сведения о параметрах PAC см. в разделе Обновления общей конфигурации.

#Обновление компонента 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. Сохраните изменения и выйдите. Operator автоматически обновит TektonInstallerSet и применит изменения.

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

Чтобы обновить версию компонента PAC, обновите Tekton Operator:

1. Обновите Tekton Operator до нужной версии
2. Operator автоматически:
   • удалит старый 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. Проверьте, не перезапускаются ли pod'ы (замените <pac-namespace> на ваш namespace PAC):

   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. Проверьте логи pod'ов на наличие ошибок:

   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: "New Application Name"

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

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

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

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

spec:
  settings:
    # For cluster-internal Hub in different namespace
    hub-url: "http://tekton-hub-api.<your-namespace>:8000/v1"
    
    # Or for external/public 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

#Отключение remote tasks

spec:
  settings:
    remote-tasks: "false"

#Настройка пользовательских ссылок на console

Чтобы интегрировать PAC с вашей пользовательской console, настройте пользовательские ссылки на console. Это позволяет ссылкам на статус pipeline в Git provider (GitLab, GitHub и т. д.) вести в вашу пользовательскую console.

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

spec:
  settings:
    # Custom console display name
    custom-console-name: "My Console"
    
    # Base URL for the custom console (Console entry point)
    custom-console-url: "https://console.example.com"
    
    # URL template for PipelineRun details page
    # Format: /console-acp/workspace/{{ namespace }}~CLUSTER_NAME~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}
    # Replace CLUSTER_NAME with your actual cluster name (e.g., 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 template for TaskRun log page
    # Format: /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 template for namespace pipeline list page
    # Format: /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 - для кластера business 1
• dev-cluster - для кластера разработки

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

Шаг 2. Укажите URL console

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

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

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

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

• {{ namespace }}: namespace, в котором выполняется PipelineRun
• {{ pr }}: имя PipelineRun
• {{ task }}: имя Task в PipelineRun

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

Для кластера с именем my-cluster и console по адресу 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 и task build-task в namespace 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

• Список pipeline в namespace:

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

Эти ссылки будут отображаться в UI вашего Git provider (merge request'ы GitLab, pull request'ы GitHub и т. д.), позволяя разработчикам быстро переходить в вашу пользовательскую console.

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

#Удаление CR OpenShiftPipelinesAsCode

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

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

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

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

Operator автоматически:

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

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

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

Убедитесь, что CR OpenShiftPipelinesAsCode удален:

kubectl get openshiftpipelinesascodes.operator.tekton.dev

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

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

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

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

No resources found

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

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

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

No resources found

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

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

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

Если у вас созданы CR Repository для интеграции с Git provider:

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

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

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

#Удаление Secret'ов

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

Secrets, которые очищаются автоматически (в namespace PAC):

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

Secrets, которые нужно очищать вручную (в namespace'ах CR Repository):

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

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

1. Перечислите все secrets в namespace, где находятся CR Repository:

   kubectl get secrets -n <namespace>

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

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

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

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

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

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

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

• secrets могут использоваться несколькими CR Repository или другими ресурсами
• удаление secret, который все еще используется, приведет к сбоям аутентификации
• всегда проверяйте, что secret не используется где-либо еще, прежде чем удалять его

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

secret "gitlab-secret" deleted

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

Если вы создавали Ingress или Service типа NodePort для PAC (замените <pac-namespace> на ваш 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

#Диагностика неполадок

#Pod'ы PAC не запускаются

Проверьте логи pod'ов (замените <pac-namespace> на ваш 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 — это внутренний ресурс operator. Если возникли проблемы с ним, не изменяйте и не удаляйте его напрямую. Вместо этого выполняйте диагностику через CR OpenShiftPipelinesAsCode.

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

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

Если в TektonInstallerSet отображаются ошибки:

1. Проверьте статус CR OpenShiftPipelinesAsCode на наличие базовых проблем
2. Изучите логи operator для получения подробных сообщений об ошибках
3. При необходимости удалите и создайте заново CR OpenShiftPipelinesAsCode (operator автоматически пересоздаст 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 не удаляется, проверьте наличие finalizer'ов:

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

Пример вывода (если finalizer'ы существуют):

  finalizers:
  - tekton.dev/operator

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

Если finalizer'ы присутствуют, возможно, operator все еще выполняет обработку. Подождите несколько минут и попробуйте снова.

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

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

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

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

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

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

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

• Настроить репозиторий
• Поддерживать код pipeline
• Запускать pipeline