如何通过Azure DevOps获取GitHub提交列表并传入Sentry用于发布？

我之前帮团队搞定过一模一样的场景——用Azure Pipelines+GitHub做CI/CD，还要给Sentry关联提交用Suspect Commits，当时也踩了文档只支持Azure DevOps仓库的坑，分享下我们的解决方案：

核心思路很简单：既然代码托管在GitHub，我们直接在Azure Pipelines里拉取GitHub的提交历史，再调用Sentry的Release API把提交列表传进去就行，完全不需要依赖Azure DevOps仓库。

步骤1：在Azure Pipelines中获取GitHub提交列表 #

首先要确保你的Pipeline已经和GitHub正确集成（比如配置了GitHub Service Connection），这样能正常拉取代码和访问Git历史。下面两种方法任选一种：

方法A：用Git命令直接获取提交哈希（推荐，简单高效） #

如果你的发布是基于版本标签（比如v1.2.3）或者增量构建，用Git命令就能拿到两次版本之间的所有提交：

# 在Bash任务中执行：
# 获取当前构建的完整Commit SHA
CURRENT_COMMIT=$(git rev-parse HEAD)
# 获取最近的正式版本标签（如果是首次发布可以跳过这步，直接用初始commit）
LAST_RELEASE_TAG=$(git describe --abbrev=0 --tags)
# 拉取两次版本之间的所有提交哈希，每行一个
COMMITS=$(git log --pretty=format:"%H" $LAST_RELEASE_TAG..$CURRENT_COMMIT)
# 转成Sentry需要的JSON数组格式
COMMITS_JSON=$(echo "$COMMITS" | jq -R . | jq -s .)
# 存入Pipeline变量，供后续任务使用
echo "##vso[task.setvariable variable=SentryCommits]$COMMITS_JSON"

⚠️ 注意：如果你的Pipeline用了浅克隆（默认可能是fetchDepth: 1），git log会拿不到历史提交，需要在Checkout任务里设置fetchDepth: 0（完整克隆），或者设置足够大的深度覆盖上次发布到当前的提交数。

方法B：调用GitHub API获取提交（适合复杂场景） #

如果需要更灵活的筛选（比如按时间范围、分支），可以调用GitHub的REST API：

# 需提前在Pipeline安全变量中配置GitHub PAT（要有repo权限）
GITHUB_PAT=$(env:GITHUB_PAT)
OWNER="你的GitHub用户名/组织名"
REPO="你的仓库名"
# 获取当前分支的最新Commit SHA
CURRENT_COMMIT=$(git rev-parse HEAD)
# 获取上次发布的时间戳（可以从Azure变量组或上次发布记录中读取）
LAST_RELEASE_TIMESTAMP="2024-01-01T00:00:00Z"

# 调用API获取提交列表
COMMITS=$(curl -H "Authorization: token $GITHUB_PAT" \
  "https://api.github.com/repos/$OWNER/$REPO/commits?sha=$CURRENT_COMMIT&since=$LAST_RELEASE_TIMESTAMP" | jq -r '.[].sha')
# 转成JSON数组
COMMITS_JSON=$(echo "$COMMITS" | jq -R . | jq -s .)
echo "##vso[task.setvariable variable=SentryCommits]$COMMITS_JSON"

步骤2：调用Sentry API创建关联提交的Release #

接下来要把获取到的提交列表传给Sentry，完成Release的创建和关联：

1. 准备Sentry凭证：在Sentry中创建一个Internal Integration，勾选project:releases权限，生成Auth Token，把这个Token存在Azure Pipelines的安全变量中（比如SENTRY_AUTH_TOKEN）。
2. 添加Pipeline任务调用API：

# 配置Sentry组织和项目信息
SENTRY_ORG="你的Sentry组织Slug"
SENTRY_PROJECT="你的Sentry项目Slug"
# 用标签或Commit SHA作为Release版本号
RELEASE_VERSION=$(git describe --tags --always)

# 调用Sentry Create Release API
curl -X POST "https://sentry.io/api/0/organizations/$SENTRY_ORG/releases/" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "version": "'"$RELEASE_VERSION"'",
    "projects": ["'"$SENTRY_PROJECT"'"],
    "commits": '"$COMMITS_JSON"'
  }'

执行完这个任务后，去Sentry的Release页面就能看到关联的提交列表，Suspect Commits功能也能正常定位引发问题的代码提交了。

关键注意事项（你可能忽略的点） #

• 关联GitHub和Sentry仓库：一定要在Sentry项目的Settings > Integrations > GitHub中配置仓库关联，这样Sentry才能拉取提交的详细信息（作者、提交消息、代码变更），否则只会显示哈希值。
• 版本号一致性：确保Sentry的Release版本号和你应用中打的版本号完全一致（比如应用的package.json版本、Docker镜像标签），这样Sentry才能正确关联错误和Release。
• 增量构建的版本追踪：如果是频繁发布的增量构建，建议把上次发布的版本号存在Azure Pipelines的变量组中，每次发布成功后更新这个变量，避免git describe在多分支场景下获取到错误的标签。
• PR构建的特殊处理：如果是PR的测试构建，不需要创建正式的Sentry Release，可以给版本号加前缀（比如pr-$(System.PullRequest.PullRequestId)-$(git rev-parse --short HEAD)），避免和正式版本冲突。

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