如何通过GitHub Actions REST API关联重运行与原运行（仿UI分组）

1. 通过GitHub API拉取目标分支的工作流运行 #

调用GitHub REST API的GET /repos/{owner}/{repo}/actions/runs接口，指定branch参数筛选目标分支的所有运行。返回的每个运行对象里，有三个核心字段用于识别重运行关联：

• id：当前运行的唯一标识ID
• run_attempt：运行的尝试次数，首次运行值为1，每重运行一次递增1
• parent_workflow_run_id：若为重运行，该字段会指向它所重运行的原始运行的id

示例curl请求：

curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
  "https://api.github.com/repos/OWNER/REPO/actions/runs?branch=YOUR_TARGET_BRANCH&per_page=100"

2. 梳理重运行关联关系 #

拿到返回数据后，按以下逻辑处理：

• 先将所有运行以id为键存入字典，方便快速查找对应运行
• 遍历每个运行：
  • 若parent_workflow_run_id不为空，直接将该运行关联到对应ID的原始运行
  • 结合run_attempt字段辅助验证：值大于1的必然是重运行
• 最终将原始运行与它的所有重运行整理为分组，比如用字典存储，key为原始运行ID，value为包含原始运行和所有重运行的列表

对应你给出的示例场景（01、02、03为首次运行，04是01的重运行，05是03的重运行）：

• 01的run_attempt=1，parent_workflow_run_id为空
• 04的run_attempt=2，parent_workflow_run_id等于01的ID
• 03的run_attempt=1，parent_workflow_run_id为空
• 05的run_attempt=2，parent_workflow_run_id等于03的ID

整理后的分组为：

• 组1：[01, 04]
• 组2：[02]
• 组3：[03, 05]

3. 模拟UI下拉菜单的展示逻辑 #

要实现类似GitHub UI的下拉关联效果，可按以下方式处理：

• 优先展示所有首次运行（run_attempt=1的运行）
• 给每个首次运行添加下拉选项，列出所有关联的重运行（即parent_workflow_run_id等于该首次运行ID的运行）
• 重运行按执行时间倒序排列，让最新的重运行排在最上方

注意：确保你的GitHub Token拥有对应仓库的访问权限（私有仓库需repo权限，公共仓库需public_repo权限）；若运行数量超过分页上限（最大100条/页），需通过返回的link头处理分页请求。

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