GitLab CI中通过API合并MR并等待对应流水线完成的问题

问题分析 #

调用GitLab Merge Request合并接口后，返回的.head_pipeline.id指向的是MR源分支的最后一条流水线，而非合并提交触发的目标分支流水线。这是因为head_pipeline字段的定义就是关联MR源分支的最新流水线，和合并后的新提交流水线无关。

解决方案步骤 #

1. 获取合并提交的SHA值
   合并MR的接口返回结果中包含.merge_commit_sha字段，这是合并后生成的新提交哈希值，用它可以精准定位对应的流水线。

2. 轮询查询合并提交对应的流水线ID
   由于流水线生成存在延迟，需要通过轮询GitLab流水线列表接口，根据合并提交SHA过滤出目标流水线。

3. 轮询流水线状态直至完成
   拿到正确的流水线ID后，持续查询其状态，直到状态变为success（成功）或failed/canceled（失败/取消）。

完整代码示例 #

# 1. 合并MR并获取合并提交SHA
MERGE_RESPONSE=$(curl --silent -X PUT "${GITLAB_BASE_URL}/${SERVICE_PROJECT_ID}/merge_requests/${MERGE_REQUEST_IID}/merge" \
  --header "Private-Token: ${PRIVATE_TOKEN}" \
  --header "Content-Type: application/json")
MERGE_COMMIT_SHA=$(echo "$MERGE_RESPONSE" | jq -r '.merge_commit_sha')

# 2. 轮询获取合并提交对应的流水线ID
MAX_WAIT=300  # 最大等待时间（秒）
WAIT_INTERVAL=5  # 轮询间隔（秒）
ELAPSED=0
PIPELINE_ID=""

while [ -z "$PIPELINE_ID" ] && [ $ELAPSED -lt $MAX_WAIT ]; do
  # 根据提交SHA查询流水线
  PIPELINE_ID=$(curl --silent "${GITLAB_BASE_URL}/${SERVICE_PROJECT_ID}/pipelines?sha=${MERGE_COMMIT_SHA}" \
    --header "Private-Token: ${PRIVATE_TOKEN}" | jq -r '.[0].id')
  
  # 处理未找到的情况
  if [ "$PIPELINE_ID" = "null" ]; then
    PIPELINE_ID=""
    sleep $WAIT_INTERVAL
    ELAPSED=$((ELAPSED + WAIT_INTERVAL))
  fi
done

# 超时处理
if [ -z "$PIPELINE_ID" ]; then
  echo "超时未找到合并提交对应的流水线"
  exit 1
fi

# 3. 轮询流水线状态
while true; do
  PIPELINE_STATUS=$(curl --silent "${GITLAB_BASE_URL}/${SERVICE_PROJECT_ID}/pipelines/${PIPELINE_ID}" \
    --header "Private-Token: ${PRIVATE_TOKEN}" | jq -r '.status')
  
  case "$PIPELINE_STATUS" in
    "success")
      echo "流水线执行成功"
      exit 0
      ;;
    "failed"|"canceled")
      echo "流水线执行失败或被取消，状态：$PIPELINE_STATUS"
      exit 1
      ;;
    *)
      echo "流水线正在执行，当前状态：$PIPELINE_STATUS，等待中..."
      sleep 10
      ;;
  esac
done

关键说明 #

• 使用merge_commit_sha作为查询条件，确保获取的是合并提交触发的流水线，避免和其他分支流水线混淆
• 设置合理的超时时间和轮询间隔，平衡等待效率和资源占用
• 完整的状态判断覆盖成功、失败、取消三种终态，避免无限等待

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