3. 门禁触发机制：基于PR/MR触发、基于标签触发、基于定时触发、基于Webhook触发

门禁（Gate）的触发时机决定了流水线在何时开始执行准入检查。在 GitOps 实践中，不同的触发机制对应不同的变更场景与风险等级。选择错误的触发方式会导致检查遗漏或流水线空转。本章详细拆解四种核心触发机制的原理、适用场景与配置要点。

3.1 触发机制总览与对比

下表从触发源、响应速度、典型场景、风险控制四个维度对比四种机制，帮助你在设计流水线时快速选型。

3.2 基于 PR/MR 触发

PR/MR 触发是 GitOps 中最核心的门禁触发方式。当开发者提交 Pull Request（GitHub/GitLab）或 Merge Request（GitLab）时，流水线自动启动准入检查。该机制在变更合入主分支之前完成所有验证，是“左移”安全策略的基石。

3.2.1 触发流程

1. 开发者创建 PR/MR，目标分支通常为 main 或 release。
2. Git 托管平台通过 Webhook 向流水线系统发送 pull_request 事件。
3. 流水线解析事件负载，提取源分支、目标分支、提交 SHA、变更文件列表。
4. 执行门禁检查：代码扫描、单元测试、安全合规、策略评估。
5. 检查结果通过 Commit Status API 回写至 PR/MR 页面，标记为 success、failure 或 pending。
6. 仅当所有门禁通过后，PR/MR 才允许合入。

3.2.2 关键配置示例（GitHub Actions）

name: GitOps Gate - PR Trigger
on:
  pull_request:
    branches: [ main, release/* ]
    types: [ opened, synchronize, reopened ]

jobs:
  gate-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Policy Check
        run: |
          # 检查是否包含 required labels
          if [[ "${{ github.event.pull_request.labels }}" != *"ready-for-review"* ]]; then
            echo "Missing required label: ready-for-review"
            exit 1
          fi
      - name: Run Security Scan
        run: trivy image --severity HIGH,CRITICAL my-app:${{ github.sha }}

3.3 基于标签触发

标签触发通常用于版本发布场景。当维护者推送符合语义化版本规范的 Git 标签（如 v1.2.3）时，流水线执行生产级门禁检查。该机制确保只有经过人工确认的版本才能进入发布流程。

3.3.1 触发规则设计

3.3.2 配置示例（GitLab CI）

stages:
  - gate

tag-gate:
  stage: gate
  only:
    - tags
  except:
    - /^rc-.*$/
  script:
    - echo "Running production gate for tag $CI_COMMIT_TAG"
    - semver-check $CI_COMMIT_TAG
    - security-scan --level critical
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/'
      when: always
    - when: never

3.4 基于定时触发

定时触发用于执行周期性、无变更驱动的门禁检查。典型场景包括：证书过期巡检、依赖漏洞扫描、环境漂移检测、合规策略审计。该机制不依赖代码变更，适合作为持续合规的“安”。

3.4.1 调度策略

• 高频巡检（每小时）： 证书状态、密钥轮换状态、关键服务健康度。
• 中频巡检（每天）： 依赖库 CVE 扫描、容器镜像漏洞更新、策略违规检测。
• 低频巡检（每周）： 合规审计报告生成、权限漂移检测、备份完整性验证。

3.4.2 配置示例（Jenkins Pipeline + Cron）

pipeline {
    triggers {
        cron('0 2 * * *')  // 每天凌晨2点执行
    }
    stages {
        stage('Scheduled Gate') {
            steps {
                script {
                    // 执行证书过期检查
                    sh 'check-cert-expiry --threshold 30d'
                    // 执行依赖漏洞扫描
                    sh 'trivy fs --severity CRITICAL .'
                    // 生成合规报告
                    sh 'generate-compliance-report --output evidence/scheduled-$(date +%Y%m%d).json'
                }
            }
        }
    }
}

3.5 基于 Webhook 触发

Webhook 触发允许外部系统（CI/CD 工具、监控系统、工单平台、安全扫描器）向流水线发送事件，驱动门禁执行。该机制是实现 GitOps 事件驱动架构的关键桥梁。

3.5.1 常见 Webhook 事件源

3.5.2 安全验证

Webhook 触发必须验证事件来源的合法性，防止伪造事件触发门禁。推荐使用 HMAC 签名验证：

// 服务端验证示例（Go）
func verifyWebhookSignature(payload []byte, signature string, secret []byte) bool {
    mac := hmac.New(sha256.New, secret)
    mac.Write(payload)
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(expected), []byte(signature))
}

3.6 触发机制架构总览

下图展示了四种触发机制在 GitOps 流水线中的集成位置与数据流向。

3.7 触发机制排障路径

门禁触发失败是流水线中最常见的故障类型。下表总结了四种触发机制的典型故障模式与排障步骤。