英文:
When does a GitHub workflow trigger for merge_group and is it restricted by branch?
问题
我正在尝试使用GitHub Actions来实现以下设置：
- 拉取请求必须经过审查、构建并通过单元测试。
- 一旦满足这些条件，它们可以添加到合并队列。
- 一旦进入合并队列，GitHub将尝试部署合并组。
- 如果部署成功，那么代码将被合并。
- 如果部署失败，有问题的拉取请求将从合并组中删除，然后我们将尝试与新的合并组再次进行。
我在GitHub Actions中有一个包含以下触发器的部署工作流程：
on:
merge_group:
我只希望此触发器针对目标为master的合并组运行。
这个触发器是否正确？
是否有一种方法可以指定它触发的分支？
英文:
I am trying to achieve a setup like this using GitHub Actions:
- Pull Requests must be reviewed, build and pass unit tests
- Once those conditions are met, they can be added to the merge queue
- Once in the merge queue, GitHub will attempt to deploy the merge group
- If the deployment succeeds, then the code is merged
- If deployment fails, the offending PR is removed from the merge group and we try again with the new merge group
I have a deployment workflow with this trigger in GitHub Actions:
on:
merge_group:
I only want this to run for merge groups that are targeting master.
Is this trigger correct?
Is there a way to specify which branches it is triggered for?
答案1
得分: 2
请注意使用合并队列的以下先决条件：
- 必须拥有由组织拥有的公共存储库，或者使用GitHub Enterprise Cloud的组织拥有的私有存储库。
- 配置合并队列需要对存储库设置具有管理员访问权限。
我发现如果只包括merge_group触发器，工作流将无法运行。相反，您应该同时添加pull_request和merge_group触发器，并为每个作业筛选github merge_group事件，如下所示：
（基于https://github.com/orgs/community/discussions/51120#discussioncomment-6312578）
on:
pull_request:
merge_group:
jobs:
deployment:
if: ${{ github.event_name == 'merge_group' }}
然后，在GitHub存储库设置 -> 分支保护规则中，为您要应用队列的分支创建规则（最有可能是main，我相信目前仅支持一个队列）。
勾选“要求状态检查通过后才能合并”复选框，并在所需的状态检查下方添加您希望从工作流中运行的作业的名称（在此示例中，将是deployment）。
勾选“要求合并队列”复选框，并根据适合您存储库的选项进行配置。
滚动到底部并保存更改。
这个解决方法有点不太美观，因为它会跳过在打开的PR上的工作流，尽管从技术上讲它们已通过，但据我所知，这是确保合并队列中运行所需工作流的唯一方法，而不是按PR提交/推送运行。希望他们将来会改变触发行为。
英文:
Note the following prerequisites to use Merge Queue:
- Must have a public repository owned by an organization, or a private repository owned by an organization using GitHub Enterprise Cloud.
- Merge Queue configuration requires Admin Access to repository settings.
I've found that if you only include the merge_group trigger, the workflow will fail to run. Instead, you should add both pull_request and merge_group triggers, as well as filter for the github merge_group event for each job like so:
(based on https://github.com/orgs/community/discussions/51120#discussioncomment-6312578)
on:
pull_request:
merge_group:
jobs:
deployment:
if: ${{ github.event_name == 'merge_group' }}
Then, in the GitHub repository Settings -> Branch Protection Rules, create a rule for the branch you want to apply the queue to (most likely main, I believe currently only having 1 queue is supported).
Check the box for "Require status checks to pass before merging" and add the names of the jobs you want to run from your workflow under required status checks (in this example, it would be deployment).
Check the box for "Require merge queue" and configure options according to what suits your repository.
Scroll to the bottom and Save changes.
This workaround is a little bit ugly as it will have skipped workflows on open PRs that technically pass, but as far as I can tell, this is the only way to ensure the workflow you want runs in merge queue without running per PR commit/push. Hopefully they will change the trigger behavior in the future.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论