GitHub Actions:如何构建合并请求的合并请求? [英] GitHub Actions: how to build a pull request as if it were merged?

问题描述

我对GitHub Actions感到非常兴奋.

我现在使用Travis-CI和AppVeyor，它们具有"PR"(拉动请求)构建，可以像合并拉动请求一样构建代码.

我想使用GitHub Actions进行持续集成，但是GitHub Actions似乎仅支持构建推送的提交，而不是合并的结果.如何达到我想要的效果?

解决方案

根据

当我运行 git fetch origin pull/10/merge:merge-pr-10 来获取合并提交时，我得到的提交是 f1ea865 ，是将 ec81c6f 添加到 44a09bc (这是创建PR时我的 master 分支上的最新提交).并注意实际构建的SHA:

因此，只需在[pull_request] 上使用作为我的工作流程的触发事件，它就可以实现我想要的.如果您查看公关的历史，您会发现我尝试了几件事来查看触发新构建的原因是:添加评论，关闭存储库，打开存储库...这就是我的发现.

• 添加评论没有不触发新的工作流程运行
• 按下新的提交 DID 触发新的工作流程运行
• 关闭PR不会不触发新的工作流程运行
• 重新打开PR DID 触发新的工作流程运行
• 向PR添加标签确实没有否触发新的工作流程运行
• 从PR中删除标签确实否触发了新的工作流程运行

这就是我所期望的.

I'm very excited about GitHub Actions.

I use Travis-CI and AppVeyor now, which have "PR" (pull request) builds that build the code as if the pull request were merged.

I would like to use GitHub Actions for continuous integration, but it seems GitHub Actions only supports building pushed commits, not the result of the merge. How do I achieve the effect I want?

解决方案

According to https://github.com/actions/checkout/issues/15#issuecomment-524093065 and https://github.com/actions/checkout/issues/15#issuecomment-524107344, if you set your workflow to trigger on the pull_request event rather than the push event, the GITHUB_SHA will be the merge commit, so the checkout action will check out the result of the merge, which you can then build and run unit tests on.

Disclaimer: I haven't gotten into the beta yet, so I can't verify this information for myself; I can just pass on what others have said worked for them.

I've gotten into the beta now, so I can confirm that this works. I ran a build of the following workflow in my test repo:

name: Build PR

on: [pull_request]

jobs:
  build:

    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macOS-latest]
        dotnet: [2.2.402, 3.0.100-rc1-014190]
    runs-on: ${{ matrix.os }}

    steps:
    # ... trimmed ...
    - name: Dump GitHub context
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: echo "$GITHUB_CONTEXT"
      if: runner.os != 'Windows'
    # ... trimmed ...

Here's a build log of that workflow running. The PR is here; the first commit on that PR is commit ID ec81c6f:

When I ran git fetch origin pull/10/merge:merge-pr-10 to fetch the merge commit, the commit I got was f1ea865, a merge of ec81c6f onto 44a09bc (which was the latest commit on my master branch at the time that PR was created). And notice the SHA that was actually built:

So just by using on: [pull_request] as the triggering event of my workflow, it did what I wanted. If you look at the PR's history, you'll see that I tried several things to see what triggered a new build: adding a comment, closing the repo, opening the repo... Here's what I found.

• Adding a comment did NOT trigger a new workflow run
• Pushing a new commit DID trigger a new workflow run
• Closing the PR did NOT trigger a new workflow run
• Reopening the PR DID trigger a new workflow run
• Adding a label to the PR did NOT trigger a new workflow run
• Removing a label from the PR did NOT trigger a new workflow run

Which is all as I would have expected.

这篇关于GitHub Actions:如何构建合并请求的合并请求?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！