Common Issues

For All Users

本故障排除指南涵盖了管理员(组件部署、配置)和普通用户(仓库设置、流水线执行)遇到的问题。

重要提示:本文档中使用了两个不同的命名空间:

  • <pac-namespace>:部署 PAC 组件(controller、watcher、webhook)的命名空间。默认是 tekton-pipelines,但可以通过 OpenShiftPipelinesAsCode CR 中的 targetNamespace 自定义。
  • <namespace>:创建 PipelineRun 的命名空间。该命名空间在创建 Repository CR 时指定,可以是集群中的任意命名空间。

请将这些占位符替换为您实际的命名空间名称。

本文档提供了使用 Pipelines-as-Code (PAC) 时常见问题的排查步骤。

开始之前

在排查具体问题前,请先确认以下基础内容:

1. 检查 PAC 组件是否运行

确认所有 PAC pod 正常运行(将 <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

该命令显示所有 Repository CR 及其所在命名空间。命名空间列即为 PipelineRun 创建的命名空间。

3. 获取资源名称

获取 pod 名称

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

获取 Repository CR 名称

kubectl get repository -n <namespace>

获取 PipelineRun 名称

kubectl get pipelinerun -n <namespace>

4. 本文档中常用的占位符

  • <pac-namespace>:PAC 部署命名空间(默认:tekton-pipelines
  • <namespace>:PipelineRun 命名空间(根据仓库不同而异)
  • <repo-name>:Repository CR 名称(使用 kubectl get repository -n <namespace> 列出)
  • <pod-name>:Pod 名称(使用 kubectl get pods -n <pac-namespace> 列出)
  • <name>:PipelineRun 名称(使用 kubectl get pipelinerun -n <namespace> 列出)
  • <gitlab-secret>:GitLab 令牌 Secret 名称(查看 Repository CR spec)

PAC 组件未部署

现象

OpenShiftPipelinesAsCode CR 显示 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
  1. 查看 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
  1. 检查 TektonInstallerSet

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

    注意TektonInstallerSet 是集群范围资源,仅供只读排查。请勿直接修改或删除。如问题持续,请通过 OpenShiftPipelinesAsCode CR 进行排查。

示例输出:

NAME                                             AGE
openshiftpipelinesascode-main-deployment-4bzwx   153d
openshiftpipelinesascode-main-static-s7qn2       153d
openshiftpipelinesascode-post-cdwjw              153d
  1. 查看 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 状态
  • 命名空间问题:确认 targetNamespace 是否存在
  • 资源冲突:检查是否存在冲突资源

解决方案

  1. 确认 CR 名称为 pipelines-as-code
  2. 确保 Tekton Operator 正常运行
  3. 检查命名空间是否存在(将 <pac-namespace> 替换为实际 PAC 命名空间):kubectl get namespace <pac-namespace>
  4. 如有需要,删除并重新创建 CR

PAC Pods 无法启动

现象

PAC pods 处于 PendingCrashLoopBackOff 状态。

排查步骤

  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
  1. 查看 Pod 日志

    先获取 pod 名称(替换 <pac-namespace>):

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

    然后查看日志(替换 <pod-name>):

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

示例输出(示例错误):

Error: failed to start controller: cannot connect to database
  1. 查看 Pod 事件

    获取 pod 名称后,描述该 pod(替换 <pod-name>):

    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
  1. 检查资源限制

    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 未接收事件

现象

GitLab webhook 事件未到达 PAC,流水线未触发。

排查步骤

  1. 检查 GitLab 中的 Webhook 配置

    • 进入 GitLab 项目 → 设置 → Webhooks
    • 确认 webhook URL 正确
    • 检查 webhook secret 是否与 Repository CR 匹配
  2. 查看 PAC Controller 日志(替换 <pac-namespace>):

    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"}
  1. 从 GitLab 测试 Webhook

    • 进入 GitLab 项目 → 设置 → Webhooks
    • 点击“测试” → “Push events”
    • 检查 webhook 响应
  2. 确认 Controller 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
  1. 检查 Repository CR

    先列出所有 Repository CR(替换 <namespace>):

    kubectl get repository -n <namespace>

    然后查看指定 Repository CR(替换 <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

常见原因

  • Controller URL 不可访问:防火墙或网络问题
  • Webhook secret 不匹配:GitLab 中的 Secret 与 Repository CR 不一致
  • Webhook URL 配置错误:控制器 URL 配置错误
  • Ingress/Service 未配置:控制器未暴露

解决方案

  1. 确认控制器 URL 可从 GitLab 服务器访问
  2. 确保 GitLab 和 Repository CR 中的 webhook secret 匹配
  3. 检查 Ingress/Service 配置
  4. 使用 curl 手动测试 webhook

验证

应用解决方案后,验证问题是否解决:

  1. 从 GitLab 测试 webhook

    • 进入 GitLab 项目 → 设置 → Webhooks
    • 点击“测试” → “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 事件被接收的日志条目。

流水线未触发

现象

Git 事件发生时,流水线未被创建。

排查步骤

  1. 检查流水线注解

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

示例输出:

pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
pipelinesascode.tekton.dev/on-event: "[push]"
  1. 确认分支名称匹配

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

示例输出:

main
abc1234 Test commit
  1. 查看 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"}
  1. 检查 Repository CR 状态

    先列出 Repository CR(替换 <namespace>):

    kubectl get repository -n <namespace>

    然后查看指定 Repository CR(替换 <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
  1. 确认流水线文件存在

    git ls-files .tekton/

示例输出:

.tekton/pipelinerun.yaml

常见原因

  • 注解语法错误:注解格式不正确
  • 分支名称不匹配:分支模式与实际分支不符
  • 流水线文件未找到:文件不在预期位置
  • 路径过滤:变更文件不匹配路径过滤规则
  • Repository CR 未找到:无匹配的 Repository CR

解决方案

  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. 确认 Repository CR 存在且匹配仓库 URL

验证

应用解决方案后,验证问题是否解决:

  1. 触发测试事件

    • 向注解指定的分支推送提交
    • 或创建合并请求以测试 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"}
  1. 检查 Repository CR

    先列出 Repository CR(替换 <namespace>):

    kubectl get repository -n <namespace>

    然后查看指定 Repository CR(替换 <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:
# ......
  1. 确认命名空间存在

    kubectl get namespace <namespace>

示例输出:

NAME                STATUS   AGE
project-pipelines   Active   10m

如果命名空间不存在,会看到:

Error from server (NotFound): namespaces "project-pipelines" not found
  1. 检查 RBAC 权限

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

示例输出:

yes
  1. 检查 GitLab 令牌

    先从 Repository CR 获取 Secret 名称:

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

    然后查看 Secret(替换 <gitlab-secret>):

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

示例输出(简略,令牌为 base64 编码):

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

常见原因

  • 命名空间不存在:目标命名空间未创建
  • RBAC 权限不足:PAC ServiceAccount 缺少权限
  • GitLab 令牌无效:令牌过期或错误
  • 流水线定义错误:YAML 或 Tekton 语法无效
  • 仓库访问失败:无法访问 Git 仓库

解决方案

  1. 创建缺失的命名空间:

    kubectl create namespace <namespace>

示例输出:

namespace/project-pipelines created
  1. 验证 RBAC:检查 ServiceAccount 和 RoleBindings

    查看 PAC 使用的 ServiceAccount:

    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>
  2. 更新过期的 GitLab 令牌

  3. 验证流水线 YAML 语法

  4. 测试 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 事件(推送或创建 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>):

    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'
  1. 检查任务引用

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

示例输出:

taskRef:
  name: my-task
  kind: Task
  1. 确认任务存在

    # 本地任务
    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"
  }
}
  1. 检查网络连通性

    # 测试访问 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
...

常见原因

  • 任务名称错误:任务名拼写错误
  • 任务不在当前命名空间:任务定义在其他命名空间
  • Tekton Hub 不可用:访问 Tekton Hub 网络问题
  • 远程 URL 不可访问:无法从远程 URL 获取任务
  • 任务解析器配置错误:解析器配置有误

解决方案

  1. 核对任务名称拼写
  2. 确认任务存在于正确命名空间
  3. 测试 Tekton Hub 网络连通性
  4. 确认远程 URL 可访问
  5. 检查任务解析器配置

变量未解析

现象

流水线变量如 {{revision}} 未被替换。

排查步骤

  1. 检查变量语法

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

示例输出:

revision: {{revision}}
repo_url: {{repo_url}}
  1. 使用 Dry-Run 验证 YAML 语法

    使用 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 controller 日志。

  1. 查看 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}}"}
  1. 确认变量名称

    • {{revision}} - 正确
    • {{Revision}}{{REVISION}} - 错误(区分大小写)
    • 使用双大括号包裹:{{variable_name}}
  2. 检查 PipelineRun 参数

    先获取 PipelineRun 名称:

    kubectl get pipelinerun -n <namespace>

    然后查看参数(替换 <name>):

    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. 确保变量适用于当前事件类型,部分变量仅在特定事件中可用
  4. 如有需要,升级 PAC 至最新版本

完整变量列表请参见 Parameterizing Commits and URLs

验证

应用解决方案后,验证问题是否解决:

  1. 检查创建的 PipelineRun 中变量是否被替换

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

    变量应被替换为实际值(如 {{revision}} 应替换为提交 SHA)。

  2. 查看 PAC Controller 日志中的变量解析情况

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

    不应出现未知变量的警告。

状态未上报至 GitLab

现象

流水线运行成功,但 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"}
  1. 检查 GitLab 令牌

    先从 Repository CR 获取 Secret 名称:

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

    然后查看 Secret(替换 <gitlab-secret>):

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

示例输出(简略,令牌为 base64 编码):

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-secret
data:
  token: Z2xwYXQt...
  1. 测试 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"

示例输出(令牌有效时):

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

令牌无效或过期时:

{
  "message": "401 Unauthorized"
}
  1. 检查 Repository CR

    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
  1. 确认 PipelineRun 状态

    列出 PipelineRun:

    kubectl get pipelinerun -n <namespace>

    查看状态(替换 <name>):

    kubectl get pipelinerun <name> -n <namespace>

示例输出:

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

常见原因

  • GitLab 令牌无效:令牌过期或错误
  • 令牌权限不足:缺少所需权限范围
  • 网络问题:无法访问 GitLab API
  • PAC Watcher 未运行:Watcher pod 未运行
  • Repository CR 配置错误:GitLab 配置不正确

解决方案

  1. 确认 GitLab 令牌有效且未过期
  2. 确保令牌具有 api 权限范围
  3. 测试 GitLab API 连接
  4. 检查 PAC Watcher pod 是否运行
  5. 验证 Repository CR 中的 GitLab 配置

验证

应用解决方案后,验证问题是否解决:

  1. 查看 PAC Watcher 日志中状态更新

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

    应看到状态更新成功的日志条目。

  2. 检查 GitLab UI

    • 进入您的 GitLab 项目
    • 查看合并请求或提交
    • 确认流水线状态显示(如“passed”、“failed”、“running”)
  3. 确认 PipelineRun 已完成

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

    PipelineRun 应显示 SucceededFailed 状态,且该状态应反映在 GitLab 中。

评论命令无效

现象

评论命令如 /retest 未触发流水线。

排查步骤

  1. 检查注解配置

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

示例输出:

pipelinesascode.tekton.dev/on-comment: "retest"
  1. 确认评论格式

    • 命令必须单独一行或行首
    • /retest - 正确
    • Please /retest - 错误(命令不在行首)
  2. 查看 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"}
  1. 确认合并请求存在

    • 评论命令仅在合并请求中有效
    • 普通提交不支持
  2. 检查 Webhook 配置

    # 在 GitLab 中,确认 webhook 包含“Comments”触发事件

常见原因

  • 缺少注解:未配置 on-comment 注解
  • 命令格式错误:命令不在行首
  • 非合并请求环境:评论命令仅支持合并请求
  • Webhook 未配置:未启用评论事件触发
  • 命令名称不匹配:评论中的命令与注解不一致

解决方案

  1. 添加 on-comment 注解:pipelinesascode.tekton.dev/on-comment: "retest"
  2. 确保命令位于行首
  3. 仅在合并请求中使用命令
  4. 在 GitLab webhook 配置中启用“Comments”事件
  5. 命令名称完全匹配(区分大小写)

获取帮助

如果仍有问题:

  1. 查看日志:检查所有组件日志中的错误
  2. 确认配置:仔细检查所有配置文件
  3. 查阅文档:参考本指南中的 PAC 文档
  4. 复查排查内容:查看本文档其他排查章节

后续步骤