GitHub操作在错误的分支上运行工作流

Question

我为GitHub Actions提供了以下.github/workflows/ci.yml文件（已删除一些代码以使该问题更容易理解）：

name: CI
on:
  push:
  release:
    types: [published]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # ...
  deploy-staging:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' && github.ref == 'staging'
    steps:
      # ...

我经历了以下步骤：

1. 在develop分支上进行一些提交，然后推送这些更改。
2. 在GitHub Actions上进行构建后，我从develop到staging进行了快速向前合并。

我希望GitHub Actions在项目2之后运行test和deploy-staging作业。但是相反，它只是再次运行test而没有运行deploy-staging。

正如您在上方看到的那样，即使推送到staging，它仍然在develop分支而不是staging分支上运行。我有点假设这可能是由于快进合并的某些怪异行为造成的。但是GitHub显然意识到我推动了staging，因为它提供了从该分支创建master的PR。

因此，这让我重新思考了为什么它试图在develop而不是staging上运行的理论。

为什么会这样？反正有什么办法可以解决，因此合并到staging中实际上是在staging上而不是develop上运行工作流程？

Answer 1

${{ github.ref }}将是refs/heads/staging，而不仅仅是staging。

在这些情况下，最好的办法就是在要执行的步骤中回显要检查的变量值：

    steps:
      - name: Check inputs
        run: |
          echo github.ref is: ${{ github.ref }}
          echo github.event_name is: ${{ github.event_name }}

Answer 2

我的方法是将触发器和相关作业分成不同的工作流程。

因此，为了模仿您的示例，我将使用两个文件来代替ci.yml：

• test.yml
• deploy-staging.yml

---

在.github/workflows/test.yml中：

name: Test
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # ...

在.github/workflows/release-staging.yml中：

name: Release Staging

on:
  push:
    branches:
      - staging

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      # test steps ...
      # release ...

诚然，这很烦人，因为该发行版无法与测试在同一测试上运行，但是您要确保所有测试都在部署之前通过。

如果要链接测试运行工作流程以运行部署工作流程，我可能会更改release-staging以使用Check suite event而不是推送。