如何处理Tekton中对并发敏感的PipelineRuns及Tasks并保证执行顺序？

针对你提到的版本管理环节（SemVer生成、源码打版本、Git打标签推送）的并发冲突问题，以下是几种实用的Tekton解决方案：

方案1：基于ConfigMap的互斥锁Task #

在Pipeline开头添加一个获取锁的Task，确保同一时间只有一个PipelineRun执行版本相关操作；执行完成后再添加释放锁的Task，避免锁残留。

锁Task定义示例 #

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: acquire-lock
spec:
  steps:
    - name: acquire-lock
      image: alpine/k8s:1.26.0
      script: |
        #!/bin/sh
        LOCK_NAME="version-management-lock"
        # 尝试创建锁ConfigMap
        if kubectl create configmap $LOCK_NAME --from-literal=lock=$(context.pipelineRun.name) --dry-run=client -o yaml | kubectl apply -f -; then
          echo "锁获取成功"
        else
          # 锁已存在，检查持有锁的PipelineRun状态
          LOCK_OWNER=$(kubectl get configmap $LOCK_NAME -o jsonpath='{.data.lock}')
          while kubectl get pipelinerun $LOCK_OWNER > /dev/null 2>&1; do
            echo "等待锁持有者 $LOCK_OWNER 释放，间隔10秒重试..."
            sleep 10
          done
          # 前持有者已完成，重新获取锁
          kubectl create configmap $LOCK_NAME --from-literal=lock=$(context.pipelineRun.name) --dry-run=client -o yaml | kubectl apply -f -
          echo "等待后成功获取锁"
        fi
---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: release-lock
spec:
  steps:
    - name: release-lock
      image: alpine/k8s:1.26.0
      script: |
        #!/bin/sh
        LOCK_NAME="version-management-lock"
        # 仅当前PipelineRun是锁持有者时释放
        CURRENT_OWNER=$(kubectl get configmap $LOCK_NAME -o jsonpath='{.data.lock}')
        if [ "$CURRENT_OWNER" = "$(context.pipelineRun.name)" ]; then
          kubectl delete configmap $LOCK_NAME
          echo "锁释放成功"
        else
          echo "非锁持有者，跳过释放操作"
        fi

在Pipeline中集成锁 #

将acquire-lock设为首个Task，release-lock设为最终Task（确保无论执行结果如何都释放锁）：

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: version-management-pipeline
spec:
  tasks:
    - name: acquire-lock
      taskRef:
        name: acquire-lock
    - name: generate-semver
      taskRef:
        name: generate-semver
      runAfter: [acquire-lock]
    - name: update-source-version
      taskRef:
        name: update-source-version
      runAfter: [generate-semver]
    - name: git-tag-push
      taskRef:
        name: git-tag-push
      runAfter: [update-source-version]
    - name: release-lock
      taskRef:
        name: release-lock
      runAfter: [git-tag-push]
      finally: true  # 强制执行，避免锁残留

方案2：利用PipelineRun优先级与自定义队列控制器 #

如果集群规模较大、PipelineRun数量多，可以通过配置PipelineRun优先级类，结合自定义Kubernetes控制器实现串行队列调度。这种方式需要额外部署控制器，适合复杂场景的批量串行管理。

方案3：Git仓库分支保护补充 #

如果版本操作基于特定分支（如main），可以在Git仓库设置分支保护规则，禁止并行推送标签或版本修改；配合Tekton Task的失败重试机制，间接避免并发冲突。这是外部依赖方案，可作为前两种方案的补充。

注意事项 #

• 确保执行锁Task的ServiceAccount拥有configmaps资源的create、get、delete权限。
• 必须为release-lock设置finally: true，防止PipelineRun失败导致锁无法释放。
• 若多套Pipeline存在锁需求，建议为ConfigMap添加命名空间隔离，避免跨Pipeline的锁冲突。

内容的提问来源于stack exchange，提问作者Byebye