GitHub Checks API下Check Suite与Check Run事件数量及ID不匹配问题咨询

• 首先基础认知存在偏差：GitHub 不会仅为单次提交生成1个Check Suite，Check Suite的生成逻辑和仓库启用的GitHub App、提交触发的场景直接相关：
  • 每一个获得仓库Checks权限、且配置了Checks事件监听的GitHub App，单次符合触发条件的提交都会为该App独立生成1个Check Suite，这是单次提交出现多Suite的核心原因。比如仓库同时启用了自定义CI App、CodeQL扫描App、第三方Lint App，单次提交就会生成3个独立ID的Check Suite。
  • PR场景下会额外触发Suite生成：除了PR HEAD提交对应的SHA，GitHub还会为PR的合并预览虚拟SHA生成独立的Check Suite，如果你仅启用1个Checks App，PR场景就会出现2个Suite，和观测结果完全吻合。
  • 若提交同时属于多个开放PR、或同时推送到多个关联分支，也会额外触发对应场景的Suite生成。
• Check Run数量不固定、ID和Suite不匹配的原因：
  • Check Run归属于对应App的Check Suite，单个App可在自己的Suite下创建任意数量的Check Run，比如开发的CI App可以分别创建单元测试、代码规范检查、构建验证3个独立Run，自然会出现多Run的情况。
  • 不同ID的Check Run属于不同App生成的Check Suite，可通过事件payload中的app.id字段区分归属，同一App生成的Suite和Run的app.id完全一致。
  • 观测到的同一Suite的requested和completed事件属于同一个Check Suite的不同生命周期事件，并非两个独立Suite，可核对check_suite.id字段确认，两个事件的Suite ID完全相同，仅事件触发时机不同。
• 对应观测场景的解释：
  • commit1场景：启用了2个具备Checks权限的App，第一个App触发requested事件后创建了2个Run，所有Run执行完成后触发该Suite的completed事件；第二个App未配置自动创建Run逻辑，所以仅生成Suite没有对应Run。
  • commit4场景：当时的仓库共启用了4个具备Checks权限的App，其中2个App各创建2个Run，另外2个App各创建1个Run，累加后就是4个Suite、6个Run，和观测数值吻合。
  • PR场景：启用了1个Checks App，针对提交SHA和合并预览SHA各生成1个Suite，每个Suite下创建2个Run，刚好对应2个Suite、4个Run的观测结果。

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