#Распространённые проблемы

В этом документе приведены шаги по устранению распространённых проблем, возникающих при использовании Pipelines-as-Code (PAC).

#Перед началом

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

#1. Проверьте, что компоненты PAC запущены

Убедитесь, что все pods PAC запущены (замените <pac-namespace> на ваш namespace PAC, по умолчанию tekton-pipelines):

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

Пример вывода (все pods должны иметь состояние Running):

NAME                                          READY   STATUS    RESTARTS   AGE
pipelines-as-code-controller-769bf5c88c-xxxxx  1/1     Running   0          113d
pipelines-as-code-watcher-546d6cd86d-xxxxx     1/1     Running   15         113d
pipelines-as-code-webhook-5fcd94db5b-xxxxx     1/1     Running   0          113d

#2. Определите свои namespace

Получите namespace PAC (где развёрнуты компоненты PAC):

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

Если команда завершается с ошибкой или возвращает пустой результат, используйте значение по умолчанию: tekton-pipelines

Получите namespace Pipeline (где создаются PipelineRuns):

kubectl get repository -A

Это покажет все CR Repository и их namespace. В столбце namespace указано, где будут создаваться PipelineRuns.

#3. Получите имена ресурсов

Получите имена pods:

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

Получите имена CR Repository:

kubectl get repository -n <namespace>

Получите имена PipelineRun:

kubectl get pipelinerun -n <namespace>

#4. Распространённые заполнители, используемые в этом документе

• <pac-namespace>: namespace развертывания PAC (по умолчанию: tekton-pipelines)
• <namespace>: namespace PipelineRun (зависит от repository)
• <repo-name>: имя CR Repository (используйте kubectl get repository -n <namespace> для списка)
• <pod-name>: имя pod (используйте kubectl get pods -n <pac-namespace> для списка)
• <name>: имя PipelineRun (используйте kubectl get pipelinerun -n <namespace> для списка)
• <gitlab-secret>: имя secret с токеном GitLab (проверьте spec CR Repository)

#Компонент PAC не развёртывается

#Симптом

CR OpenShiftPipelinesAsCode показывает Ready: False, либо pods не запускаются.

#Шаги по устранению неполадок

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

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

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

apiVersion: operator.tekton.dev/v1alpha1
kind: OpenShiftPipelinesAsCode
metadata:
  name: pipelines-as-code
status:
  conditions:
  - status: "False"
    type: Ready
    reason: DeploymentFailed

2. Проверьте события CR:

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

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

Name:         pipelines-as-code
Status:       False
Events:
Type     Reason           Age   From              Message
----     ------           ----  ----              -------
Warning  DeploymentFailed 5m    tekton-operator   Failed to deploy PAC component

3. Проверьте TektonInstallerSet:

   kubectl get tektoninstallersets | grep openshiftpipelinesascode
   kubectl describe tektoninstallerset <name>

   Примечание: TektonInstallerSet — ресурс cluster-scoped. Это только проверка для чтения при устранении неполадок. Не изменяйте и не удаляйте его напрямую. Если проблема сохраняется, выполняйте диагностику через CR OpenShiftPipelinesAsCode.

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

NAME                                             AGE
openshiftpipelinesascode-main-deployment-4bzwx   153d
openshiftpipelinesascode-main-static-s7qn2       153d
openshiftpipelinesascode-post-cdwjw              153d

4. Проверьте логи Operator:

   kubectl logs -n <pac-namespace> -l app=tekton-operator --tail=100

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

{"level":"error","ts":"2024-01-01T12:00:00Z","logger":"operator","msg":"Failed to deploy PAC","error":"..."}

#Распространённые причины

• Неверное имя CR: Должно быть точно pipelines-as-code
• Operator не запущен: Проверьте статус Tekton Operator
• Проблемы с namespace: Убедитесь, что targetNamespace существует
• Конфликты ресурсов: Проверьте наличие существующих ресурсов

#Решение

1. Убедитесь, что имя CR — pipelines-as-code
2. Убедитесь, что Tekton Operator запущен
3. Проверьте, что namespace существует (замените <pac-namespace> на фактический namespace PAC): kubectl get namespace <pac-namespace>
4. При необходимости удалите и создайте CR заново

#Pods PAC не запускаются

#Симптом

Pods PAC находятся в состоянии Pending или CrashLoopBackOff.

#Шаги по устранению неполадок

1. Проверьте состояние Pod (замените <pac-namespace> на ваш namespace PAC):

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

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

NAME                                          READY   STATUS             RESTARTS   AGE
pipelines-as-code-controller-769bf5c88c-xxxxx  0/1     CrashLoopBackOff   5          113d
pipelines-as-code-watcher-546d6cd86d-xxxxx    0/1     Pending            0          113d

2. Проверьте логи Pod:

   Сначала получите имя pod (замените <pac-namespace> на ваш namespace PAC):

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

   Затем проверьте логи (замените <pod-name> на фактическое имя pod):

   kubectl logs -n <pac-namespace> <pod-name>

Пример вывода (пример ошибки):

Error: failed to start controller: cannot connect to database

3. Проверьте события Pod:

   Сначала получите имя pod, затем выполните его описание (замените <pod-name> на фактическое имя pod):

   kubectl describe pod <pod-name> -n <pac-namespace>

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

Name:         pipelines-as-code-controller-xxxxx
Status:       CrashLoopBackOff
Events:
Type     Reason     Age   From               Message
----     ------     ----  ----               -------
Warning  Failed     5m    kubelet            Error: ImagePullBackOff

4. Проверьте ограничения ресурсов:

   kubectl get pod <pod-name> -n <pac-namespace> -o yaml | grep -A 5 resources

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

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

#Webhook не получает события

#Симптом

События webhook GitLab не доходят до PAC, pipeline не запускаются.

#Шаги по устранению неполадок

1. Проверьте конфигурацию webhook в GitLab:

   • Перейдите в GitLab project → Settings → Webhooks
   • Убедитесь, что URL webhook указан правильно
   • Проверьте, что secret webhook совпадает с CR Repository

2. Проверьте логи PAC Controller (замените <pac-namespace> на ваш namespace PAC):

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=100

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

{"level":"info","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Received webhook event"}
{"level":"error","ts":"2024-01-01T12:00:01Z","logger":"controller","msg":"Webhook validation failed","error":"invalid signature"}

3. Проверьте webhook из GitLab:

   • Перейдите в GitLab project → Settings → Webhooks
   • Нажмите "Test" → "Push events"
   • Проверьте ответ webhook

4. Убедитесь, что URL Controller доступен:

   # Если используется Ingress
   curl -I http://pac.example.com

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

HTTP/1.1 200 OK
Content-Type: text/plain

# If using NodePort
curl -I http://<node-ip>:<node-port>

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

HTTP/1.1 200 OK
Content-Type: text/plain

5. Проверьте CR Repository:

   Сначала перечислите все CR Repository, чтобы найти имя (замените <namespace> на ваш namespace Pipeline):

   kubectl get repository -n <namespace>

   Затем проверьте конкретный CR Repository (замените <repo-name> на фактическое имя repository):

   kubectl get repository <repo-name> -n <namespace> -o yaml

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

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
spec:
  git_provider:
    webhook_secret:
      name: webhook-secret
      key: secret

#Распространённые причины

• URL Controller недоступен: проблемы с firewall или сетью
• Несовпадение secret webhook: secret в GitLab не совпадает с CR Repository
• Неверный URL webhook: указан неправильный URL Controller
• Ingress/Service не настроены: Controller не опубликован

#Решение

1. Убедитесь, что URL Controller доступен с серверов GitLab
2. Проверьте, что secret webhook совпадает и в GitLab, и в CR Repository
3. Проверьте конфигурацию Ingress/Service
4. Выполните ручную проверку webhook с помощью curl

#Проверка

После применения решений проверьте исправление:

1. Проверьте webhook из GitLab:

   • Перейдите в GitLab project → Settings → Webhooks
   • Нажмите "Test" → "Push events"
   • Убедитесь, что webhook возвращает ответ 200 OK

2. Проверьте логи PAC Controller для событий webhook:

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=50 | grep -i webhook

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

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

#Симптом

Pipeline не создаются при возникновении Git-событий.

#Шаги по устранению неполадок

1. Проверьте аннотации Pipeline:

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

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

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

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

   git branch --show-current
   git log --oneline -1

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

main
abc1234 Test commit

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

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=100 | grep -i trigger

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

{"level":"info","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Processing trigger","branch":"main","event":"push"}
{"level":"warn","ts":"2024-01-01T12:00:01Z","logger":"controller","msg":"Branch mismatch","expected":"main","actual":"develop"}

4. Проверьте статус CR Repository:

   Сначала перечислите CR Repository, чтобы найти имя:

   kubectl get repository -n <namespace>

   Затем проверьте CR Repository (замените <repo-name> на фактическое имя repository):

   kubectl get repository <repo-name> -n <namespace> -o yaml
   kubectl describe repository <repo-name> -n <namespace>

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

Name:         my-repo
Namespace:    project-pipelines
Status:       Ready
Events:
Type    Reason   Age   From     Message
----    ------   ----  ----     -------
Normal  Ready    5m    pac      Repository validated

5. Проверьте, что файл Pipeline существует:

   git ls-files .tekton/

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

.tekton/pipelinerun.yaml

#Распространённые причины

• Ошибка в синтаксисе аннотации: неверный формат аннотации
• Несовпадение имени ветки: шаблон ветки не соответствует фактической ветке
• Файл pipeline не найден: файл отсутствует в ожидаемом расположении
• Фильтрация по пути: изменённые файлы не соответствуют path filter
• CR Repository не найден: для repository отсутствует соответствующий CR Repository

#Решение

1. Проверьте синтаксис аннотации: используйте pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]" и pipelinesascode.tekton.dev/on-event: "[push]" вместо устаревшей аннотации on-push
2. Убедитесь, что имена веток совпадают точно (с учётом регистра)
3. Убедитесь, что .tekton/pipelinerun.yaml существует в repository
4. Проверьте path filtering, если он настроен
5. Убедитесь, что CR Repository существует и соответствует URL repository

#Проверка

После применения решений проверьте исправление:

1. Запустите тестовое событие:

   • Отправьте commit в ветку, указанную в аннотации pipeline
   • Или создайте Merge Request, если тестируете триггеры MR

2. Проверьте, создан ли PipelineRun:

   kubectl get pipelinerun -n <namespace> --sort-by=.metadata.creationTimestamp | tail -5

   После Git-события должен быть создан новый PipelineRun.

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

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=50 | grep -i trigger

   Найдите записи журнала, указывающие, что событие было обработано.

#PipelineRuns не создаются

#Симптом

События webhook принимаются, но PipelineRuns не создаются.

#Шаги по устранению неполадок

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

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=200

Пример вывода (пример ошибки):

{"level":"error","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Failed to create PipelineRun","error":"namespaces \"project-pipelines\" not found"}

2. Проверьте CR Repository:

   Сначала перечислите CR Repository, чтобы найти имя:

   kubectl get repository -n <namespace>

   Затем проверьте CR Repository (замените <repo-name> на фактическое имя repository):

   kubectl get repository <repo-name> -n <namespace> -o yaml
   kubectl describe repository <repo-name> -n <namespace>

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

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
spec:
# ......

3. Убедитесь, что namespace существует:

   kubectl get namespace <namespace>

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

NAME                STATUS   AGE
project-pipelines   Active   10m

Если namespace не существует, вы увидите:

Error from server (NotFound): namespaces "project-pipelines" not found

4. Проверьте права RBAC:

   kubectl auth can-i create pipelineruns --namespace <namespace>

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

yes

5. Проверьте токен GitLab:

   Сначала найдите имя secret в CR Repository:

   kubectl get repository <repo-name> -n <namespace> -o jsonpath='{.spec.git_provider.secret.name}'

   Затем проверьте secret (замените <gitlab-secret> на фактическое имя secret):

   kubectl get secret <gitlab-secret> -n <namespace> -o yaml

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

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-secret
data:
  token: Z2xwYXQt...

#Распространённые причины

• Namespace не существует: целевой namespace не создан
• Права RBAC: ServiceAccount PAC не имеет необходимых прав
• Неверный токен GitLab: токен истёк или указан неверно
• Ошибка определения pipeline: некорректный YAML или синтаксис Tekton
• Доступ к repository: нет доступа к Git repository

#Решение

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

   kubectl create namespace <namespace>

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

namespace/project-pipelines created

2. Проверьте RBAC: проверьте ServiceAccount и RoleBindings

   Узнайте, какой ServiceAccount использует PAC:

   kubectl get pod -n <pac-namespace> -l app=pipelines-as-code-controller -o jsonpath='{.items[0].spec.serviceAccountName}'

   Проверьте, есть ли у ServiceAccount необходимые права:

   kubectl auth can-i create pipelineruns --namespace <namespace> --as=system:serviceaccount:<pac-namespace>:<service-account-name>

3. Обновите токен GitLab, если он истёк

4. Проверьте синтаксис YAML pipeline

5. Проверьте токен GitLab:

   curl --header "PRIVATE-TOKEN: <token>" "https://gitlab.com/api/v4/user"

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

{
  "id": 1,
  "username": "user",
  "email": "user@example.com"
}

Если токен недействителен:

{"message":"401 Unauthorized"}

#Проверка

После применения решений проверьте исправление:

1. Запустите Git-событие (push или создание MR) и проверьте, создаётся ли PipelineRun:

   kubectl get pipelinerun -n <namespace> --sort-by=.metadata.creationTimestamp | tail -1

2. Проверьте статус PipelineRun:

   kubectl describe pipelinerun <name> -n <namespace>

   PipelineRun должен быть создан и начать выполнение.

#Tasks не найдены

#Симптом

PipelineRun завершается с ошибкой "task not found".

#Шаги по устранению неполадок

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

   Сначала перечислите PipelineRuns, чтобы найти имя:

   kubectl get pipelinerun -n <namespace>

   Затем проверьте PipelineRun (замените <name> на фактическое имя PipelineRun):

   kubectl get pipelinerun <name> -n <namespace> -o yaml
   kubectl describe pipelinerun <name> -n <namespace>

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

status:
  conditions:
  - status: "False"
    type: Succeeded
    reason: TaskNotFound
  taskRuns:
    task-run-name:
      status:
        conditions:
        - message: 'Task "my-task" not found'

2. Проверьте ссылки на Task:

   cat .tekton/pipelinerun.yaml | grep -A 5 taskRef

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

taskRef:
  name: my-task
  kind: Task

3. Убедитесь, что Task существует:

   # For local tasks
   kubectl get task <task-name> -n <namespace>

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

NAME       AGE
my-task    10m

Если Task не существует:

Error from server (NotFound): tasks.tekton.dev "my-task" not found

# For Tekton Hub tasks
curl https://api.hub.tekton.dev/v1/resource/task/<task-name>

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

{
  "id": 1,
  "name": "git-clone",
  "kind": "Task",
  "catalog": {
    "id": 1,
    "name": "Tekton"
  }
}

4. Проверьте сетевую доступность:

   # Test Tekton Hub access
   curl https://api.hub.tekton.dev/v1/resource/task/git-clone

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

{"id":1,"name":"git-clone",...}

# Проверьте доступ к remote URL
curl <remote-task-url>

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

apiVersion: tekton.dev/v1
kind: Task
...

#Распространённые причины

• Неверное имя Task: опечатка в имени task
• Task не в этом namespace: Task определён в другом namespace
• Tekton Hub недоступен: проблемы с сетью при доступе к Tekton Hub
• Remote URL недоступен: невозможно получить task с remote URL
• Ошибка resolver: неверная конфигурация resolver

#Решение

1. Проверьте правильность имени task
2. Убедитесь, что Task существует в правильном namespace
3. Проверьте подключение к Tekton Hub
4. Убедитесь, что remote URL доступен
5. Проверьте конфигурацию task resolver

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

#Симптом

Переменные pipeline, такие как {{revision}}, не заменяются.

#Шаги по устранению неполадок

1. Проверьте синтаксис переменных:

   cat .tekton/pipelinerun.yaml | grep -E "\{\{|\}\}"

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

revision: {{revision}}
repo_url: {{repo_url}}

2. Проверьте синтаксис YAML с dry-run:

   Используйте kubectl apply --dry-run=client, чтобы проверить синтаксис YAML PipelineRun и заранее выявить ошибки:

   kubectl apply --dry-run=client -f .tekton/pipelinerun.yaml -n <namespace>

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

pipelinerun.tekton.dev/my-pipeline created (dry run)

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

error: error validating ".tekton/pipelinerun.yaml": error validating data: [ValidationError(PipelineRun.spec): unknown field "invalid-field" in tekton.dev.v1.PipelineRun.spec, ...]

Примечание: Эта проверка dry-run валидирует синтаксис YAML и схему Tekton, но не проверяет подстановку переменных (переменные вроде {{revision}} останутся буквальными строками при dry-run). Для проблем с подстановкой переменных проверьте логи PAC controller.

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

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=100 | grep -i variable

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

{"level":"warn","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Unknown variable","variable":"{{Revision}}"}

4. Проверьте имена переменных:

   • {{revision}} - правильно
   • {{Revision}} или {{REVISION}} - неправильно (с учётом регистра)
   • Используйте двойные фигурные скобки: {{variable_name}}

5. Проверьте параметры PipelineRun:

   Сначала получите имя PipelineRun:

   kubectl get pipelinerun -n <namespace>

   Затем проверьте параметры (замените <name> на фактическое имя PipelineRun):

   kubectl get pipelinerun <name> -n <namespace> -o jsonpath='{.spec.params}'

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

[
  {
    "name": "revision",
    "value": "abc1234"
  },
  {
    "name": "repo_url",
    "value": "https://gitlab.com/user/repo"
  }
]

#Распространённые причины

• Ошибка синтаксиса: отсутствуют фигурные скобки или неверный формат
• Учитывается регистр: имена переменных чувствительны к регистру
• Переменная недоступна: переменная недоступна для текущего типа события (например, {{pull_request_number}} доступна только для событий pull_request)
• Версия PAC: старая версия PAC может не поддерживать некоторые переменные

#Решение

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

Полный список доступных переменных см. в Параметризация commit и URL.

#Проверка

После применения решений проверьте исправление:

1. Проверьте, что переменные подставлены в созданном PipelineRun:

   kubectl get pipelinerun <name> -n <namespace> -o jsonpath='{.spec.params}' | jq .

   Переменные должны быть заменены фактическими значениями (например, {{revision}} должна быть заменена SHA commit).

2. Проверьте логи PAC Controller на предмет подстановки переменных:

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=50 | grep -i variable

   Не должно быть предупреждений о неизвестных переменных.

#Статус не передаётся в GitLab

#Симптом

Pipeline успешно выполняются, но статус не отображается в GitLab.

#Шаги по устранению неполадок

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

   kubectl logs -n <pac-namespace> -l app.kubernetes.io/name=watcher --tail=100

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

{"level":"error","ts":"2024-01-01T12:00:00Z","logger":"watcher","msg":"Failed to update status","error":"401 Unauthorized"}

2. Проверьте токен GitLab:

   Сначала найдите имя secret в CR Repository:

   kubectl get repository <repo-name> -n <namespace> -o jsonpath='{.spec.git_provider.secret.name}'

   Затем проверьте secret (замените <gitlab-secret> на фактическое имя secret):

   kubectl get secret <gitlab-secret> -n <namespace> -o yaml

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

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-secret
data:
  token: Z2xwYXQt...

3. Проверьте доступ к API GitLab:

   TOKEN=$(kubectl get secret <gitlab-secret> -n <namespace> -o jsonpath='{.data.token}' | base64 -d)
   curl --header "PRIVATE-TOKEN: $TOKEN" "https://gitlab.com/api/v4/user"

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

{
  "id": 1,
  "username": "user",
  "email": "user@example.com"
}

Если токен недействителен или истёк:

{
  "message": "401 Unauthorized"
}

4. Проверьте CR Repository:

   kubectl get repository <repo-name> -n <namespace> -o yaml

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

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
spec:
  git_provider:
    secret:
      name: gitlab-secret
      key: token

5. Проверьте статус PipelineRun:

   Перечислите PipelineRuns, чтобы найти имя:

   kubectl get pipelinerun -n <namespace>

   Затем проверьте статус (замените <name> на фактическое имя PipelineRun):

   kubectl get pipelinerun <name> -n <namespace>

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

NAME                    STARTED        DURATION   STATUS
simple-pipeline-xxxxx   5 minutes ago  30s        Succeeded

#Распространённые причины

• Неверный токен GitLab: токен истёк или указан неверно
• Права токена: у token отсутствуют необходимые scopes
• Проблемы с сетью: невозможен доступ к API GitLab
• PAC Watcher не запущен: pod Watcher не работает
• CR Repository настроен неверно: неверная конфигурация GitLab

#Решение

1. Убедитесь, что токен GitLab действителен и не истёк
2. Убедитесь, что у token есть scope api
3. Проверьте доступность API GitLab
4. Убедитесь, что pod PAC Watcher запущен
5. Проверьте конфигурацию GitLab в CR Repository

#Проверка

После применения решений проверьте исправление:

1. Проверьте логи PAC Watcher на наличие успешных обновлений статуса:

   kubectl logs -n <pac-namespace> -l app.kubernetes.io/name=watcher --tail=50 | grep -i status

   Вы должны увидеть записи журнала, указывающие, что обновления статуса были успешно отправлены.

2. Проверьте интерфейс GitLab:

   • Перейдите в ваш GitLab project
   • Проверьте Merge Request или commit
   • Убедитесь, что статус pipeline отображается (например, "passed", "failed", "running")

3. Убедитесь, что PipelineRun завершился:

   kubectl get pipelinerun -n <namespace> --sort-by=.metadata.creationTimestamp | tail -1

   Для PipelineRun должен отображаться статус Succeeded или Failed, и этот статус должен быть отражён в GitLab.

#Команды комментариев не работают

#Симптом

Команды комментариев, такие как /retest, не запускают pipeline.

#Шаги по устранению неполадок

1. Проверьте конфигурацию аннотаций:

   cat .tekton/pipelinerun.yaml | grep on-comment

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

   pipelinesascode.tekton.dev/on-comment: "retest"

2. Проверьте формат комментария:

   • Команды должны быть на отдельной строке или в начале строки
   • /retest - правильно
   • Please /retest - неправильно (команда не в начале строки)

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

   kubectl logs -n <pac-namespace> -l app=pipelines-as-code-controller --tail=100 | grep -i comment

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

   {"level":"info","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Processing comment command","command":"/retest"}
   {"level":"warn","ts":"2024-01-01T12:00:01Z","logger":"controller","msg":"Comment command not at start of line","comment":"Please /retest"}

4. Убедитесь, что существует Merge Request:

   • Команды комментариев работают только в Merge Request
   • Для обычных commit они недоступны

5. Проверьте конфигурацию webhook:

   # In GitLab, verify webhook includes "Comments" trigger

#Распространённые причины

• Аннотация отсутствует: аннотация on-comment не настроена
• Формат команды: команда не находится в начале строки
• Не в Merge Request: команды комментариев работают только в Merge Request
• Webhook не настроен: событие комментариев не включено в webhook
• Несовпадение имени команды: команда в комментарии не совпадает с аннотацией

#Решение

1. Добавьте аннотацию on-comment: pipelinesascode.tekton.dev/on-comment: "retest"
2. Убедитесь, что команды находятся в начале строки
3. Используйте команды только в Merge Request
4. Включите "Comments" в конфигурации GitLab webhook
5. Указывайте имена команд точно (с учётом регистра)

#Получение помощи

Если проблемы по-прежнему сохраняются:

1. Проверьте логи: просмотрите логи всех компонентов на наличие ошибок
2. Проверьте конфигурацию: ещё раз проверьте все файлы конфигурации
3. Изучите документацию: ознакомьтесь с документацией PAC в этом руководстве
4. Проверьте разделы по устранению неполадок: изучите другие разделы этого документа

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

• Управление компонентом PAC - руководство по развёртыванию и управлению
• Руководства - пошаговые инструкции по настройке repository
• Триггер pipeline - руководство по настройке триггеров