Github 拉取请求 - 等待报告状态
我有一个拉取请求，在 VSTS 上传递了构建，但是无论我尝试触发构建多少次，另一个检查“预期 - 等待报告状态”都不会成功。我有许多其他拉取请求，没有任何问题。
我不知道如何解决这个问题，如何调试？没有比这更具体的信息：
我应该先检查哪里来解决这个问题？
Luc*_*cia 39
长话短说
\n如果在合并之前需要进行此状态检查，请使用个人访问令牌而不是默认的secrets.GITHUB_TOKEN在 github 操作中创建此 PR：
- name: Create Pull Request\n uses: peter-evans/create-pull-request@v3\n with:\n token: ${{ secrets.YOUR_PAT }}\n如果没有，只需在受保护的分支中的存储库设置下取消选中此选项：
\n
原因
\n根据设计，触发其他 github 操作的 github 操作受到限制。所以如果你有这样的设置x must pass before branch can be merged，某些操作可能会永远陷入困境。
这也是为什么“推送一个空提交”或“关闭并重新打开 PR”可以解除它的困扰——因为这样 PR 就不再纯粹是由操作触发的。这也是切换到 PAT 有效的原因，因为使用secrets.GITHUB_TOKEN意味着此 PR 是由 github-action-initiated 发起的。使用 PAT 时，它是由用户发起的。
如何调试
\n\n\n我不知道如何解决这个问题，如何调试？没有比这更具体的信息：等待状态报告
\n
我发现其他人的调试过程通常比解决方案本身更具启发性，所以，很高兴您提出这个问题！我是这样得出结论的：
\n- \n
- 通过谷歌搜索“预期 \xe2\x80\x94 等待报告状态”，我得到了这个最佳结果，其中\xe2\x80\x8b我发现上面的设置更改在注释中模糊地描述。 \n
- 然后，通过阅读此设置的描述，我将其理解为我看到此状态的原因是因为我已将其配置为必须通过才能合并任何分支，但由于某种原因此分支不会触发它。 \n
- 因此，我考虑了是什么使该分支与正确触发的所有其他分支不同。一个很大的区别是这个 PR 是由另一个动作触发的。根据这个理论，我在谷歌上搜索了“机器人创建 PR 时不会触发 github 操作”，并得到了第一个结果，这解释了原因。 \n
- 最后，我仔细检查了其他存储库中的其他类似操作，奇怪的是，一些操作触发的 PR 在下面运行，但有些则没有。我比较了它们的定义，发现边缘的定义在创建 PR 时用作
secrets.GITHUB_TOKEN标记，而正确的定义则使用 PAT。事实上，这些 PR 的开头是这只章鱼，而正确的 PR 的开头是用户图标： \n
案件结案。
\n小智 36
对我来说最简单的解决方案是关闭 PR 然后再次打开它。之后，检查按预期执行的位置。
GitHub 上有一个按钮，可以让这一切变得非常简单。
- @MichaelChirico 不，它没有明确的批准 (8认同)
小智 17
我相信您需要仔细检查 yml 文件中的作业名称是否与所需的分支保护规则/状态检查中的名称完全相同。 请注意，它区分大小写，我花了一些时间修复这个问题，但事实证明它期望构建工作完成，而我已经构建
- 这就是答案 (3认同)
Sam*_*Sam 14
有时可能会发生这种情况，您可以做的是将空提交推送到 PR 的分支。它将重新触发您在 CI 中的所有检查。这可以使用git命令来完成。
git commit --amend --no-edit
然后强行推动你的分支。
- 如果 PR 已经批准，那么状态就会过时，因为修改会更改提交哈希 (2认同)
- `git commit --allow-empty && git push` 不是更好吗？ (2认同)
Sta*_*erc 11
我找到了解决方法！您需要使用不同的分支名称为同一提交创建新的 PR。这将在完成后启动构建，原始 PR和新 PR 都将获得状态更新。然后您可以合并原来的并关闭新的。
如果 PR 是从远程存储库创建的，您可以按照以下说明将引用拉取到本地存储库：
git fetch origin pull/{id}/head:temporary
git push origin temporary