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

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

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

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

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

Убедитесь, что все pods PAC находятся в состоянии Running (замените <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 (где создаются PipelineRun):

kubectl get repository -A

Эта команда показывает все CR Repository и их namespace. Столбец namespace показывает, где будут создаваться PipelineRun.

#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 — это ресурс уровня кластера. Для диагностики выполняйте только проверку на чтение. Не изменяйте и не удаляйте его напрямую. Если проблема сохраняется, выполняйте диагностику через 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. Проверьте логи controller PAC (замените <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:

   # If using 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. Проверьте логи controller PAC на наличие событий 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. Проверьте логи controller PAC:

   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 не найден: файл находится не в ожидаемом месте
• Фильтрация по пути: изменённые файлы не соответствуют фильтру пути
• 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. Проверьте фильтрацию по пути, если она настроена
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. Проверьте логи controller PAC:

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

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

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

#Симптом

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

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

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

   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

Пример вывода (сокращённо, token закодирован в 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"

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

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

Если token недействителен:

{"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:

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

   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",...}

# Test remote URL access
curl <remote-task-url>

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

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

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

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

#Решение

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

#Переменные не разрешаются

#Симптом

Переменные 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 останутся в виде строковых литералов). Для проблем с разрешением переменных проверьте логи controller PAC.

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

   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. Проверьте логи controller PAC на наличие разрешения переменных:

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

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

#Статус не отправляется в GitLab

#Симптом

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

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

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

   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

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

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

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

   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"

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

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

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

{
  "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:

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

   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: токен истёк или указан неверно
• Права токена: у токена нет необходимых scopes
• Проблемы с сетью: невозможно достичь GitLab API
• PAC Watcher не запущен: pod watcher не работает
• Неверная конфигурация CR Repository: некорректная настройка GitLab

#Решение

1. Убедитесь, что токен GitLab действителен и не истёк
2. Убедитесь, что у токена есть scope api
3. Проверьте доступность GitLab API
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. Проверьте UI GitLab:

   • Перейдите в ваш проект GitLab
   • Проверьте 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. Проверьте логи controller PAC:

   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 Requests
   • Для обычных commit они недоступны

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

   # In GitLab, verify webhook includes "Comments" trigger

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

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

#Решение

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

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

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

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

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

• Управление компонентом PAC — руководство по развертыванию и управлению
• Настройка Repository — руководство по настройке repository
• Запуск pipeline — руководство по настройке триггеров