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

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

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

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

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

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

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

Пример вывода (все pod-ы должны быть в состоянии 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. Определите ваши пространства имён

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

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

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

Получить пространство имён Pipeline (где создаются PipelineRun):

kubectl get repository -A

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

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

Получить имена pod-ов:

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>: пространство имён для развёртывания PAC (по умолчанию: tekton-pipelines)
• <namespace>: пространство имён PipelineRun (зависит от репозитория)
• <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>: имя секрета с токеном GitLab (проверьте spec Repository CR)

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

#Симптом

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

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

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. Проверьте логи оператора:

   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
• Оператор не запущен: проверьте статус Tekton Operator
• Проблемы с пространством имён: проверьте, что targetNamespace существует
• Конфликты ресурсов: проверьте наличие существующих ресурсов

#Решение

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

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

#Симптом

Pod-ы PAC находятся в состоянии Pending или CrashLoopBackOff.

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

1. Проверьте статус pod-ов (замените <pac-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> на ваше пространство имён 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 → Settings → Webhooks
   • Убедитесь, что URL webhook указан правильно
   • Проверьте, что секрет webhook совпадает с секретом в CR Repository

2. Проверьте логи контроллера PAC (замените <pac-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 → Settings → Webhooks
   • Нажмите "Test" → "Push events"
   • Проверьте ответ webhook

4. Проверьте доступность URL контроллера:

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

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

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

# Если используется NodePort
curl -I http://<node-ip>:<node-port>

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

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

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

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

   kubectl get repository -n <namespace>

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

   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 контроллера недоступен: проблемы с файрволом или сетью
• Несовпадение секрета webhook: секрет в GitLab не совпадает с CR Repository
• Неправильный URL webhook: неверно настроен URL контроллера
• Ingress/Service не настроены: контроллер не доступен извне

#Решение

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

#Проверка

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

1. Протестируйте webhook из GitLab:

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

2. Проверьте логи контроллера 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. Проверьте логи контроллера 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> на фактическое имя репозитория):

   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 не найден: отсутствует соответствующий 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 существует в репозитории
4. Проверьте фильтрацию по путям, если она настроена
5. Убедитесь, что CR Repository существует и соответствует URL репозитория

#Проверка

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

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

   • Сделайте push коммита в ветку, указанную в аннотации pipeline
   • Или создайте Merge Request, если тестируете триггеры MR

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

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

   Вы должны увидеть новый PipelineRun, созданный после события Git.

3. Проверьте логи контроллера PAC:

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

   Ищите записи лога, указывающие на обработку события.

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

#Симптом

События webhook получены, но PipelineRun не создаются.

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

1. Проверьте логи контроллера 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> на фактическое имя репозитория):

   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. Проверьте, что пространство имён существует:

   kubectl get namespace <namespace>

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

NAME                STATUS   AGE
project-pipelines   Active   10m

Если пространство имён не существует, вы увидите:

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

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

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

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

yes

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

   Сначала найдите имя секрета из CR Repository:

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

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

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

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

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

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

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

#Решение

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

   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 должен быть создан и начать выполнение.

#Задачи не найдены

#Симптом

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. Проверьте ссылки на задачи:

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

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

taskRef:
  name: my-task
  kind: Task

3. Проверьте, что задача существует:

   # Для локальных задач
   kubectl get task <task-name> -n <namespace>

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

NAME       AGE
my-task    10m

Если задача не найдена:

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

# Для задач из Tekton Hub
curl https://api.hub.tekton.dev/v1/resource/task/<task-name>

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

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

4. Проверьте сетевое подключение:

   # Проверка доступа к Tekton Hub
   curl https://api.hub.tekton.dev/v1/resource/task/git-clone

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

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

# Проверка доступа к удалённому URL задачи
curl <remote-task-url>

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

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

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

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

#Решение

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

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

#Симптом

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

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

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

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

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

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

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

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

   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.

3. Проверьте логи контроллера 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 до последней версии при необходимости

Полный список доступных переменных смотрите в разделе Parameterizing Commits and URLs.

#Проверка

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

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

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

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

2. Проверьте логи контроллера 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:

   Сначала найдите имя секрета из CR Repository:

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

   Затем проверьте секрет (замените <gitlab-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:

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

#Решение

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

#Проверка

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

1. Проверьте логи watcher PAC на успешные обновления статуса:

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

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

2. Проверьте UI GitLab:

   • Перейдите в ваш проект GitLab
   • Проверьте Merge Request или коммит
   • Убедитесь, что статус 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:

   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
   • Не работают для обычных коммитов

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

   # В GitLab убедитесь, что webhook включает триггер "Comments"

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

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

#Решение

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

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

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

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

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

• Manage PAC Component - Руководство по развёртыванию и управлению
• Configure Repository - Руководство по настройке репозитория
• Trigger Pipelines - Руководство по настройке триггеров pipeline