GitHub Action 工作流未运行

我有一个 GitHub 动作工作流文件@myrepo/. GitHub/workflow/Build Webpage.yml，它包含以下内容:

name: Webpage Build


on:
push:
branches:
- webpage


jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: setup node
uses: actions/setup-node@v2-beta
with:
node-version: '12'
- name: install deps and predeploy
run: |
npm ci
npm run predeploy
- name: Deploy
uses: JamesIves/github-pages-deploy-action@3.5.2
with:
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
BRANCH: gh-pages
FOLDER: build

当我按到网页分支时，action 选项卡里什么都没有发生，我不知道我是否有语法错误，或者是否完全没有正确设置，我过去在这个回购中出现过与语法有关的错误，比如 every step must define a 'uses' or 'run' key，这对我来说表明 Github 确实认识到了工作流

76119 次浏览
小开
最佳答案

因此，正如在文章本身下面的注释中所发现的那样，如果您希望工作流在分支 x 上运行，可以使用。Github 文件夹必须位于分支 x 上，以及您希望从中触发工作流的任何其他分支上

小开

你的分公司是 master还是 main？

在未来这可能是愚蠢的，但至于2020年10月只有 请记住，默认的 GitHub 分支已经从 ABC0重命名为 main(来源)

因此，如果您是从其他地方复制粘贴行动，请确保您的目标是正确的分支(对于新的回购，这意味着大多数时间取代 master与 .yml工作流文件中的 main)。

如果您的目标是错误的分支，那么操作的名称将出现在 GitHub 上，但是实际上不会运行任何操作。

希望在这个过渡期能帮到别人！

小开

只是想加上一个发生在我身上的愚蠢的案例。无论何时添加新的工作流，有时可能会发生工作流可能无法进入运行阶段，即使在正确地指定了所有内容之后也是如此。只要确保在添加操作本身之后，在运行该操作的任何分支中进行一些更改。请确保也提交这些更改。这将触发运行操作并显示在仪表板上。

小开
  • 又一个发生在我身上的愚蠢案例。由于 GitHub UI 在文件夹路径中添加了空格(有时这是由 Google Translate 插件引起的) ，当我从 GitHub UI 中复制路径 .github/workflows并用它在 VSCode 中创建文件夹时，它是 .github / workflows，/周围有空格。

GitHub workflow path

  • 我通过要求 GitHub 从 Actions选项卡为我初始化 Actions 工作流来发现这个问题，所以我注意到了我的错误，以及 这是解决这个问题的好办法。

GitHub Actions UI

小开

还有一种情况，假设您在项目中已经有 workflow文件，并且如果您的 paths设置，那么工作流将不会运行，除非您在 path文件夹中进行更改。因此，如果你对 workflow做任何改变，保持在 path之外的 workflow不会触发 Action

on:
push:
branches:
- master
paths:
- 'packages/container/**'
小开

另一个需要注意的陷阱是: 如果您分叉了另一个具有 Github 工作流的存储库，默认情况下，将在您的 fork 中禁用工作流。

这个特性的目的是防止您意外地运行具有未知行为的导入工作流，这可能会构成安全风险(例如访问机密)。

要重新启用工作流，请转到存储库的“ Actions”选项卡，并确认您了解要启用的工作流。

小开

我遇到了这个问题，没有一个答案是有帮助的。它就是跑不动，也说不通为什么。 直到我发现 Github 的操作中断了，检查一下 https://www.githubstatus.com/的 href = “ https://www.githubstatus.com/”rel = “ norefrer”

小开

最后需要注意的是提交中触发操作的跳过关键字。

如果你的 push 或者 PR 的 HEAD 提交包含字符串[跳过 ci ] ，[ ci 跳过] ，[ no ci ] ，[跳过操作] ，或者[操作跳过]在 push 或 pull _ request 事件上触发的工作流将被跳过。

在使用语义发布并将部署分支重置为发布提交时，我被这个问题所困扰。您可以在部署分支中重写发布提交和推送(至少我是这样解决的)。

小开

工作流中可能出现的其他可能性如下，其类型为 pull_request。

如果与分支和基本分支发生冲突，则不会触发工作流。这并不总是显而易见的，因为您可能遇到的唯一冲突就是与工作流的冲突。

下面只是一个例子，但重点是冲突必须首先得到解决。

on:
pull_request:
types: [labeled, reopened, synchronize, ready_for_review]
小开

我发现我的问题在 GitHub 的操作文档中有描述:

方法定义一个分支！字符，则还必须定义至少一个分支，而不使用！性格。如果您只想排除分支，那么可以使用分支-忽略。

最初，我在我的工作流程中使用了这个(它没有触发操作) :

on:
push:
branches:
- "!main"

解决办法:

on:
push:
branches-ignore:
- main
小开

在我的例子中，我的工作流没有触发，因为我在 bash 命令中使用了双引号，这搞乱了 yml 解析。

你可以通过 VSCode 查看语法突显是否看起来不正常。

小开

请注意，不能使用嵌套文件夹 不会被 Github 识别。在我的情况下，我不得不改为 .github/workflows/my_workflow.yml

小开

对我来说，不小心把文件夹命名为 .github/workspaces而不是 .github/workflows。

小开

在我的例子中，我需要在 pylint 分支中运行一个工作流，但是直到我在主分支中添加了相同的工作流，它才能正常工作。在主分支中，我添加了 .github/workflows，然后是我想要运行的工作流的 yml 文件。

完成这一步之后，我转到 pylint 分支，然后在工作流中在分支下添加 pylint。执行此工作流之后，每次提交之后都会触发该工作流

name: Python Notebooks Linting
on:
push:
branches:
- 'main'
- 'pylint'
小开

确保你的。Push 和 pull _ request 上的 yml 文件是正确的目标。先看看你的主枝，是主枝还是主枝？

on:
push:
branches: [ main/master ]
pull_request:
branches: [ main/master ]

提交答案