#管理 PAC Component

本指南说明如何在 Kubernetes 平台上部署、更新和卸载 Pipelines-as-Code (PAC) component。

#前提条件

在管理 PAC 之前，请确保你具备以下条件：

• Kubernetes 集群（版本 1.24 或更高）
• 已安装并运行 Tekton Operator
• 集群管理员权限
• 已安装并配置 kubectl 以访问你的集群

#部署 PAC Component

创建 OpenShiftPipelinesAsCode CR 以部署 PAC。示例使用默认 PAC 命名空间 tekton-pipelines；如果你设置了不同的 targetNamespace，请在命令和清单中替换它。

创建一个名为 pac.yaml 的 YAML 文件：

apiVersion: operator.tekton.dev/v1alpha1
kind: OpenShiftPipelinesAsCode
metadata:
  name: pipelines-as-code
spec:
  settings:
    application-name: Pipelines as Code CI
    remote-tasks: "true"
    secret-auto-create: "true"
  targetNamespace: tekton-pipelines  # Default namespace, you can customize this

hub-url 故意省略：operator 已在 pipelines-as-code ConfigMap 中提供了一个可用值。只有在你要将其指向不同的 Hub 时才设置它——参见 标准设置。

将 CR 应用到你的集群：

kubectl apply -f pac.yaml

检查 OpenShiftPipelinesAsCode CR 状态：

kubectl get openshiftpipelinesascodes.operator.tekton.dev

输出应显示 READY=True；VERSION 会随发布版本变化，REASON 通常为空。

NAME                  VERSION     READY   REASON
pipelines-as-code    <version>   True

验证 PAC pods 是否正在运行：

kubectl get pods -n tekton-pipelines | grep pipelines-as-code

示例输出（controller、watcher 和 webhook pods 必须处于 Running）：

NAME                                      READY   STATUS    RESTARTS   AGE
pipelines-as-code-controller-xxxxx        1/1     Running   0          5m
pipelines-as-code-watcher-xxxxx           1/1     Running   0          5m
pipelines-as-code-webhook-xxxxx           1/1     Running   0          5m

#配置访问

#使用 Gateway API

使用此方法可通过 ACP Gateway API 使用域名暴露 PAC controller。

Git provider -> PAC domain -> Envoy Gateway Service -> Gateway/HTTPRoute -> pipelines-as-code-controller

此示例使用：

• 默认 PAC 命名空间：tekton-pipelines
• GatewayClass：envoy-gateway-operator-cpaas-default
• 域名：pac.example.com

步骤 1：准备 Envoy Gateway。 安装 Alauda build of Envoy Gateway，并确保默认 GatewayClass 已被接受。参考：Envoy Gateway Operator。

kubectl get gatewayclass envoy-gateway-operator-cpaas-default

NAME                                   ACCEPTED
envoy-gateway-operator-cpaas-default   True

步骤 2：准备 LoadBalancer 地址。 Envoy Gateway Service 将创建为 type: LoadBalancer，因此 LoadBalancer Services 必须能够获取外部 IP。在 ACP 裸金属集群上，请安装并配置 Alauda Container Platform Load Balancer for MetalLB。参考：Configure MetalLB。

kubectl get ipaddresspool,l2advertisement -A

预期结果：

NAMESPACE        NAME                                    ADDRESSES
metallb-system   ipaddresspool.metallb.io/default-pool   ["192.168.1.100-192.168.1.110"]

步骤 3：创建 Gateway API 资源。 创建 gateway-api.yaml。按需替换 tekton-pipelines、envoy-gateway-operator-cpaas-default 和 pac.example.com。参考：Configure GatewayAPI Gateway 和 Configure GatewayAPI Route。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: pipelines-as-code
  namespace: tekton-pipelines
spec:
  infrastructure:
    parametersRef:
      group: gateway.envoyproxy.io
      kind: EnvoyProxy
      name: pipelines-as-code
  gatewayClassName: envoy-gateway-operator-cpaas-default
  listeners:
    - name: http
      port: 80
      hostname: pac.example.com
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: pipelines-as-code
  namespace: tekton-pipelines
spec:
  provider:
    kubernetes:
      envoyService:
        type: LoadBalancer
      envoyDeployment:
        replicas: 1
        container:
          imageRepository: registry.alauda.cn:60080/acp/envoyproxy/envoy
          resources:
            limits:
              cpu: "1"
              memory: 1Gi
            requests:
              cpu: 100m
              memory: 256Mi
    type: Kubernetes
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: pipelines-as-code
  namespace: tekton-pipelines
spec:
  hostnames:
    - pac.example.com
  parentRefs:
    - name: pipelines-as-code
      sectionName: http
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: pipelines-as-code-controller
          port: 8080

应用该文件：

kubectl apply -f gateway-api.yaml

预期结果：

gateway.gateway.networking.k8s.io/pipelines-as-code created
envoyproxy.gateway.envoyproxy.io/pipelines-as-code created
httproute.gateway.networking.k8s.io/pipelines-as-code created

步骤 4：获取外部地址。 检查生成的 Envoy Service：

kubectl get svc -A \
  -l gateway.envoyproxy.io/owning-gateway-name=pipelines-as-code,gateway.envoyproxy.io/owning-gateway-namespace=tekton-pipelines

预期结果：

NAMESPACE                  NAME                                                 TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)
envoy-gateway-operator    envoy-tekton-pipelines-pipelines-as-code-3f8c88ad    LoadBalancer   10.96.10.20     192.168.1.100   80:32176/TCP

步骤 5：验证并获取 webhook URL。 确保 Git provider 能够解析并访问 PAC 域名。常见做法是创建一个 DNS A 记录。例如，如果 Service 的 EXTERNAL-IP 是 192.168.1.100，则创建：

Type: A
Name: pac.example.com
Value: 192.168.1.100

如果 DNS 还未就绪，或者你只想从当前机器测试该路由，请使用 curl --resolve：

EXTERNAL_IP=$(kubectl get svc -A \
  -l gateway.envoyproxy.io/owning-gateway-name=pipelines-as-code,gateway.envoyproxy.io/owning-gateway-namespace=tekton-pipelines \
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

kubectl get gateway pipelines-as-code -n tekton-pipelines
kubectl get httproute pipelines-as-code -n tekton-pipelines -o yaml
curl -i --resolve "pac.example.com:80:${EXTERNAL_IP}" http://pac.example.com/

预期结果：

• Service 具有 EXTERNAL-IP。
• Gateway 显示 PROGRAMMED=True。
• HTTPRoute 已被接受。
• curl 返回 PAC controller 响应。

在该域名可被 Git provider 网络访问后，打印 URL：

WEBHOOK_URL=http://pac.example.com

WEBHOOK_URL 就是 PAC webhook URL。请在 Git provider 中注册此值，或在 tkn pac create repo 提示输入 webhook URL 时填写它。

如果你改为通过 ACP ALB 或其他 Ingress Controller 暴露 PAC，请使用 使用 Ingress。

注意：

• HTTPRoute 会转发到现有的 pipelines-as-code-controller Service 的 8080 端口；不要将其指向名为 pipelines-as-code-webhook 的 admission webhook Service。
• 如果生成的 Envoy Service 仍为 EXTERNAL-IP=<pending>，请检查集群 LoadBalancer provider。对于 MetalLB，参见 Configure MetalLB。
• 关于 Gateway API 选项，例如保留 VIP、无主机路由或 HTTPS listeners，请参见 Configure GatewayAPI Gateway 和 Configure GatewayAPI Route。

#使用 Ingress

当集群中已经有 Ingress Controller，并且你希望通过 Ingress 域名暴露 PAC controller 时，请使用此方法。

此示例使用：

• 默认 PAC 命名空间：tekton-pipelines
• 域名：pac.example.com

步骤 1：准备 Ingress Controller。 确保已安装并就绪 Ingress Controller。参考：Configure Ingress。

步骤 2：创建 Ingress 资源。 创建 ingress.yaml。按需替换 tekton-pipelines 和 pac.example.com。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: tekton-pipelines
spec:
  rules:
  - host: pac.example.com
    http:
      paths:
      - backend:
          service:
            name: pipelines-as-code-controller
            port:
              number: 8080
        path: /
        pathType: Prefix

应用该文件：

kubectl apply -f ingress.yaml

预期结果：

ingress.networking.k8s.io/pipelines-as-code created

步骤 3：验证 Ingress 地址。 检查该 Ingress 是否具有地址：

kubectl get ingress pipelines-as-code -n tekton-pipelines

预期结果：

NAME                CLASS   HOSTS             ADDRESS         PORTS
pipelines-as-code   nginx   pac.example.com   192.168.1.100   80

步骤 4：获取 webhook URL。 确保 Git provider 能够通过 Ingress 地址解析并访问 pac.example.com。然后打印 URL：

HOST=$(kubectl get ingress pipelines-as-code -n tekton-pipelines \
  -o jsonpath='{.spec.rules[0].host}')

echo "WEBHOOK_URL=http://${HOST}"

WEBHOOK_URL 就是 PAC webhook URL。请在 Git provider 中注册此值，或在 tkn pac create repo 提示输入 webhook URL 时填写它。

如果你没有 DNS 名称，请删除 host 字段，并改用可访问的 Ingress IP URL。

可选：启用 HTTPS。 在 tekton-pipelines 中创建一个 TLS Secret，并向同一个 Ingress 添加 tls 部分。证书必须与 pac.example.com 匹配。

kubectl create secret tls pipelines-as-code-tls \
  -n tekton-pipelines \
  --cert=tls.crt \
  --key=tls.key

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pipelines-as-code
  namespace: tekton-pipelines
spec:
  rules:
  - host: pac.example.com
    http:
      paths:
      - backend:
          service:
            name: pipelines-as-code-controller
            port:
              number: 8080
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - pac.example.com
    secretName: pipelines-as-code-tls

配置 TLS 后，请使用 HTTPS webhook URL：

echo "WEBHOOK_URL=https://${HOST}"

#使用 NodePort

创建一个 NodePort Service：

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

重要：

• targetPort 必须是 8082，这是 PAC controller pod 监听 webhook 事件的端口
• port（8080）是 Service 端口（用于集群内部通信）
• nodePort（30080）是可从集群外部访问的外部端口
• 对于 Ingress，Service 端口是 8080，它会在内部路由到 controller 的 8082 端口

从可访问的节点 IP 和生成的 NodePort 打印 URL：

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

NODE_IP=$(kubectl get nodes \
  -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}')

echo "WEBHOOK_URL=http://${NODE_IP}:${NODEPORT}"

WEBHOOK_URL 就是 PAC webhook URL。请在 Git provider 中注册此值，或在 tkn pac create repo 提示输入 webhook URL 时填写它。

#配置设置

PAC 配置位于 OpenShiftPipelinesAsCode CR 的两个不同位置：spec.settings 和 spec.options.configMaps。你必须使用哪一个取决于具体 key。在编辑之前请先阅读 将每个设置放在哪里，因为写到错误位置的 key 会被丢弃且不会报错。

#标准设置

这些 key 位于 spec.settings 下：

hub-url 指向 PAC controller 在解析远程 task 时查询的 Hub。operator 已提供一个可用值，因此除非你要将 PAC 指向不同的 Hub，否则请保持这三个 hub 设置未配置。要查看你的集群实际使用的值：

kubectl -n tekton-pipelines get configmap pipelines-as-code \
  -o jsonpath='{.data.hub-url}{"\n"}{.data.hub-catalog-type}{"\n"}'

如果你将 hub-url 指向 Tekton Hub 实例，则必须同时设置 hub-catalog-type: tekton。默认提供的值是 artifacthub，而仅设置 hub-url 不会改变它，因此 PAC 将使用 ArtifactHub API 访问 Tekton Hub，从而无法解析 task。

custom-console-* 设置会重写 PAC 发回 Git provider 的集群侧 link，使其指向平台 console 而不是 OpenShift Console。操作流程见 配置自定义 Console 链接。

#Alauda 扩展设置

这些 key 是 Alauda 在上游 Pipelines as Code 之上的扩展。它们必须位于 spec.options.configMaps 下，而不是 spec.settings 下：

操作流程：配置自定义 Console 链接 适用于 custom-console-url-namespace-vars，以及 在 Push Events 上配置 Pull Request Number 适用于另外两个。

#将每个设置放在哪里

这两个位置由 operator 中完全不同的代码路径处理：

• spec.settings 不会按你写入的内容直接存储。operator 的默认化 webhook 会先将你的 map 解析为上游 Pipelines as Code settings struct，然后再根据该 struct 重新生成 map。凡是该 struct 中没有对应字段的 key——也就是上面列出的每个 Alauda 扩展设置——都会被静默丢弃：CR 会丢失该 key，生成的 pipelines-as-code ConfigMap 永远收不到它，并且不会报告任何错误或事件。
• spec.options.configMaps 由 additional-options transformer 处理，它是最后运行的 transformer，会将你的条目逐个按 key 合并到渲染后的 ConfigMap 中。之后不会再有任何东西重写这个 map，因此任何 key 都会保留下来——包括 operator 不认识的 key。

有三点值得记住：

• 将上游 key 放在 spec.settings 下，将 Alauda 扩展 key 放在 spec.options.configMaps 下。不要无故把上游 key 移到 options 中：settings 是它们文档化且经过验证的位置。
• 如果同一个 key 在两个位置都设置了，则 spec.options.configMaps 的值会生效，因为该 transformer 在基于 settings 的 ConfigMap 渲染之后运行。
• 设置 spec.options.disabled: true 会关闭整个 transformer。此时 spec.options 下的所有内容都会被忽略，包括这些设置，你会回到静默丢弃的行为。请保持其未设置或为 false。

spec.options.configMaps 是一个以 ConfigMap 名称为键的 map——它可以作用于组件清单中的任何 ConfigMap，如果该名称不存在则会创建一个。PAC 从名为 pipelines-as-code 的 ConfigMap 中读取其设置，因此这里应使用这个 key：

apiVersion: operator.tekton.dev/v1alpha1
kind: OpenShiftPipelinesAsCode
metadata:
  name: pipelines-as-code
spec:
  targetNamespace: tekton-pipelines
  options:
    disabled: false
    configMaps:
      pipelines-as-code:
        data:
          custom-console-url-namespace-vars: "project=label:cpaas.io/project,cluster=label:cpaas.io/cluster"

验证该 key 已进入 ConfigMap。这是唯一可靠的检查方式——从 spec.settings 读回该值并不能说明 PAC 是否收到了它：

kubectl get configmap pipelines-as-code -n tekton-pipelines \
  -o jsonpath='{.data.custom-console-url-namespace-vars}'

#更新 PAC Component

#更新配置

1. 编辑 OpenShiftPipelinesAsCode CR：

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

2. 按需更新 settings 字段：

   spec:
     settings:
       application-name: "My Custom PAC"
       remote-tasks: "true"
       error-detection-from-container-logs: "true"

   若要修改某个 Alauda 扩展设置，请改为编辑 spec.options.configMaps——这些 key 在保存时会从 spec.settings 中移除。

3. 保存并退出。operator 会自动更新 TektonInstallerSet 并应用更改。

#常见配置更新

本节中的示例会更新名为 pipelines-as-code 的 OpenShiftPipelinesAsCode CR。每个示例都会显示它所属的字段——大多数使用 spec.settings，而 Alauda 扩展设置使用 spec.options.configMaps。若不确定适用哪一个，请参阅 将每个设置放在哪里。

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

#配置自定义 Console 链接

custom-console-* 设置会重写 PAC 发回 Git provider 的集群侧 link，使其指向平台 console。下面的示例从 namespace labels 中解析 {{ project }} 和 {{ cluster }}，因此 URL 不会硬编码某个集群标识符。

请注意，三个模板化 key 位于 spec.settings 下，而 custom-console-url-namespace-vars 必须位于 spec.options.configMaps 下——参见 将每个设置放在哪里：

spec:
  targetNamespace: tekton-pipelines
  settings:
    custom-console-name: "My Console"
    custom-console-url: "https://console.example.com/console-acp/"
    custom-console-url-pr-details: "https://console.example.com/console-acp/workspace/{{ project }}~{{ cluster }}~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}"
    custom-console-url-pr-tasklog: "https://console.example.com/console-acp/workspace/{{ project }}~{{ cluster }}~{{ namespace }}/pipeline/pipelineRuns/detail/{{ pr }}?tab=task_overview&id={{ task }}"
    custom-console-url-namespace: "https://console.example.com/console-acp/workspace/{{ project }}~{{ cluster }}~{{ namespace }}/pipeline/pipelineRuns"
  options:
    disabled: false
    configMaps:
      pipelines-as-code:
        data:
          custom-console-url-namespace-vars: "project=label:cpaas.io/project,cluster=label:cpaas.io/cluster"

效果：Git provider 状态 link 会打开平台 console 中的 PipelineRun 和 task 页面，而不是默认的 OpenShift 风格占位 URL。

PAC 在发布状态 link 时会展开这些变量：

标准事件变量（{{ revision }}、{{ repo_url }} 等）也可以在这些模板中使用，此外，还有该事件解析得到的 Repository spec.params 条目——没有名称的条目，或 CEL filter 未匹配的条目，都不会传递下去。上面的五个内置名称始终优先：如果 namespace 变量或 Repository 参数复用了其中之一，则该值会被忽略，而不会覆盖它。

custom-console-url-namespace-vars 是一个以逗号分隔的列表。每个条目使用 name=label:<key> 或 name=annotation:<key>，并可带一个可选的 |<default> 回退值；当 label 或 annotation 缺失或为空时会使用该回退值。如果没有默认值，则变量会解析为空字符串，而不是保留为字面量 {{ name }}。

要实现这一点，必须满足两个条件。PAC 必须能够读取 namespace——如果 Namespace GET 失败，例如 PAC controller 对其没有权限，那么该运行不会注入任何来自 namespace 的变量。并且它读取的是创建 run 时的 Repository namespace，而最终状态上报时读取的是 PipelineRun namespace；只有当 PipelineRun 通过 target-namespace annotation 被路由到其他位置时，这两者才会不同。只要某个变量最终未被替换，generateURL 就会丢弃整个 URL 并回退到 custom-console-url，这正是“link 正确但始终不展开”的症状。

spec:
  options:
    disabled: false
    configMaps:
      pipelines-as-code:
        data:
          custom-console-url-namespace-vars: "project=label:cpaas.io/project|unknown,cluster=label:cpaas.io/cluster"

对于一个名为 my-app-build-abc123、位于 namespace my-app 中且具有 cpaas.io/project=team-a 和 cpaas.io/cluster=prod labels 的 PipelineRun，PAC 会生成如下 link：

https://console.example.com/console-acp/workspace/team-a~prod~my-app/pipeline/pipelineRuns/detail/my-app-build-abc123
https://console.example.com/console-acp/workspace/team-a~prod~my-app/pipeline/pipelineRuns/detail/my-app-build-abc123?tab=task_overview&id=build-task
https://console.example.com/console-acp/workspace/team-a~prod~my-app/pipeline/pipelineRuns

这些 URL 会出现在 commit statuses、GitHub Checks 面板和 merge request comments 中。

#在 Push Events 上配置 Pull Request Number

{{ pull_request_number }} 是一个可在 repository 中的 PipelineRun 引用的动态变量。它在 pull request event 中有明确值，但在 push event 中没有。两个 Alauda 扩展设置控制此时的行为。二者都位于 spec.options.configMaps 下，而不是 spec.settings 下：

spec:
  targetNamespace: tekton-pipelines
  options:
    disabled: false
    configMaps:
      pipelines-as-code:
        data:
          enable-pull-request-number-on-push-events: "true"
          replace-empty-template-vars-with-empty: "true"

enable-pull-request-number-on-push-events（默认 "true"）：当某个 push event 携带的 commit 属于某个 pull request 时，PAC 会将 {{ pull_request_number }} 设置为该 pull request number。如果你希望 push events 永远不继承 pull request number，请将其设为 "false"——例如当 pipeline 使用该变量来判断自己是否正在为某个 pull request 运行时。

它也只会在 PAC 仍然处理的 push events 中生效。上游 skip-push-event-for-pr-commits 设置默认值为 "true"，并且当 pushed commit 属于一个开放的 pull request 时，它会让 PAC 直接丢弃 GitHub push event——根本不会创建 PipelineRun，因此也不会展开任何变量。其余情况仍会进入此设置：tag pushes（跳过规则从不适用它们）；其 commit 仅关联已关闭或已合并 pull request 的 pushes，这通常是 merge 产生的 push；以及当 skip-push-event-for-pr-commits 设为 "false" 后的每一个 push event。

replace-empty-template-vars-with-empty（默认 "false"）：控制 PAC 如何处理无法解析的模板变量。默认情况下，未解析的 {{ pull_request_number }} 会作为字面字符串 {{ pull_request_number }} 留在 PipelineRun 中，这通常会表现为一个不合理的参数值或校验失败。将其设为 "true" 可改为用空字符串替换未解析变量。名称以 body、headers 或 files 开头的变量会被故意保留，因为它们通过不同机制解析。

对于 PAC 实际处理的 GitHub push event，这两个设置的组合如下：

该表假定没有其他内容提供该名称。名为 pull_request_number 的 Repository spec.params 条目会像其他参数一样被传递，只要 PAC 没有从事件本身获取该值，模板就会解析为它。

效果：设置 replace-empty-template-vars-with-empty: "true" 后，引用 {{ pull_request_number }} 的 pipeline 在 pull request event 和 push event 上都能正常运行，而不会在 push 时失败。

#更改 Application Name

使用此设置可更改 PAC 在 Git provider 状态消息中使用的显示名称：

spec:
  settings:
    application-name: "New Application Name"

效果：Git provider checks、statuses 和 comments 会显示新的 application name。此操作不会更改 OpenShiftPipelinesAsCode resource 名称。

#启用错误检测

错误检测默认已经开启。只有在你想更改扫描的日志行数或关闭该功能时，才显式设置它：

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

效果：PAC 会扫描失败的 task 日志，并向 Git provider 反馈中添加一小段错误摘要。这是 GitHub App 功能；其他 provider 会忽略它。

#更新 Hub URL

默认情况下，PAC 从集群内 ArtifactHub Shim 解析远程 task，无需任何配置。只有在你要将 PAC 指向不同的 Hub 时才覆盖它——并且务必将 hub-catalog-type 与 hub-url 一起设置，因为否则会保留默认提供的 artifacthub 值：

spec:
  settings:
    # An ArtifactHub-compatible API (public artifacthub.io, or your own mirror)
    hub-url: "https://artifacthub.io"
    hub-catalog-type: "artifacthub"

    # Or a Tekton Hub instance — note the different catalog type
    # hub-url: "http://tekton-hub-api.devops-system:8000/v1"
    # hub-catalog-type: "tekton"

效果：PAC 会从你指定的 Hub 而不是集群内 shim 解析远程 task。

检查当前生效值：

kubectl -n tekton-pipelines get configmap pipelines-as-code \
  -o jsonpath='{.data.hub-url}{"\n"}{.data.hub-catalog-type}{"\n"}{.data.hub-catalog-name}{"\n"}'

示例输出：

http://artifacthub-shim-api.artifacthub-shim-system.svc.cluster.local
artifacthub
catalog

#禁用 Remote Tasks

使用 remote-tasks 控制 PAC 是否获取并嵌入由 PAC annotations 引用的远程资源。

spec:
  settings:
    remote-tasks: "false"

效果：当你希望阻止 PAC 从 annotation 引用中获取远程 Tasks 或 Pipelines 时，请使用 "false"。

#卸载 PAC Component

#删除 OpenShiftPipelinesAsCode CR

移除 CR 会使 operator 清理 TektonInstallerSet 以及 operator 创建的所有 PAC Deployment、Service、ConfigMap 和 RBAC 对象。

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

确认 CR、installer set 和 pods 已消失：

kubectl get openshiftpipelinesascodes.operator.tekton.dev
kubectl get tektoninstallersets -n tekton-pipelines | grep pipelinesascode
kubectl get pods -n tekton-pipelines | grep pipelines-as-code

这些命令都应返回 No resources found。

#清理 operator 不拥有的资源

operator 会删除它创建的所有内容。你自己添加的资源会保留，必须手动删除。

用户命名空间中的 Repository CRs：

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

用户命名空间中的每个 repository Secret。这些是用户在配置 repository 时创建的 Git provider access tokens（provider.token）和 webhook secrets（webhook.secret）。PAC 拥有的集群 secret（带有 app.kubernetes.io/part-of=pipelines-as-code label）会被 operator 删除；这些按 repository 创建的 Secret 不会被删除。删除前请确认每个 Secret 未被其他资源使用：

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

PAC controller 的 Gateway API resources，如果你在 配置访问 中创建了它们：

kubectl delete httproute pipelines-as-code -n tekton-pipelines
kubectl delete gateway pipelines-as-code -n tekton-pipelines
kubectl delete envoyproxy pipelines-as-code -n tekton-pipelines

PAC controller 的 Ingress / NodePort Service，如果你在 配置访问 中创建了它们：

kubectl delete ingress pipelines-as-code -n tekton-pipelines
kubectl delete service pipelines-as-code-controller-nodeport -n tekton-pipelines

#故障排查

#PAC Pods 未启动

检查 pod 日志：

kubectl logs -n tekton-pipelines -l app.kubernetes.io/part-of=pipelines-as-code

示例输出（示例日志条目）：

{"level":"info","ts":"2024-01-01T12:00:00Z","logger":"controller","msg":"Starting PAC controller"}
{"level":"info","ts":"2024-01-01T12:00:01Z","logger":"controller","msg":"PAC controller ready"}

#OpenShiftPipelinesAsCode CR 未就绪

检查 CR 状态和 events：

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

示例输出（节选）：

Name:         pipelines-as-code
Namespace:
Status:       Ready
Version:      0.x.x
Events:
  Type    Reason   Age   From              Message
  ----    ------   ----  ----              -------
  Normal  Ready    5m    tekton-operator   PAC component deployed successfully

#TektonInstallerSet 问题

当 TektonInstallerSet 未处于 Ready 时，请读取其 conditions 以及 operator 对底层 OpenShiftPipelinesAsCode CR 的视图。两者都属于只读检查；不要自行删除 installer set。

kubectl get tektoninstallersets -n tekton-pipelines -o yaml

如果错误持续存在，请重新创建 OpenShiftPipelinesAsCode CR——operator 会从头重建 installer set。

#CR 无法删除

卡住的删除通常是被 operator finalizer 持有。列出 finalizers：

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

tekton.dev/operator finalizer 表示 operator 仍在清理中；请等待后重试。空输出表示 CR 已可删除。

#资源未移除

当 pods 或 Services 在删除后仍然存在时：

kubectl delete deployment -n tekton-pipelines -l app.kubernetes.io/part-of=pipelines-as-code
kubectl delete service -n tekton-pipelines -l app.kubernetes.io/part-of=pipelines-as-code

#下一步

• Guides
• 在 Git 中定义 PipelineRuns
• 触发 PAC Pipelines