这篇博文似乎不再有效。 2020 年 7 月 GitHub 发布了对 fork的适当支持 https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/太棒了!

这篇文章应该是关于完全不同的东西。它应该是一篇关于如何轻松地使用 GitHub Actions 在项目中自动化工作流的文章。是......但当我计划这篇文章时,我正忙于我的任务。现在我差不多完成了,我第一次对 GitHub 感到失望。

GitHub Actions 自宣布以来得到了我的❤️。我不能玩它。我没有使用它,因为在我之前的项目中,我们绑定到特定的 CI 工具。然后我开始研究AsyncAPI,我非常高兴在那里介绍 GitHub Actions。

GH Actions 的第一个工作流程❤️

我是一个自动化狂。我讨厌做同样的事情两次,这就是为什么我想要改进的第一件事是 Docker 镜像发布。

哦,伙计,我喜欢它。从 GitHub Actions 开始非常简单。谷歌搜索基础非常简单。他们还为刚从 Actions 开始的新手提供了这个超级棒的 UI。甚至工作流文件的编辑看起来也与其他文件不同。具有花哨的自动完成和 linting 的工作流有一个专用视图。干得好 GitHub,干得好!!!使用 GitHub 与使用 TravisCI 一样棒,但无需离开 GitHub UI。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--wFqw5m3r--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to -uploads.s3.amazonaws.com/i/fwzv0hgv35ktoiksijne.png)

你可以想象,当我了解到GitHub Actions Hackathon时,我会非常兴奋,我就像“地狱,是的,我很想参加”。

现在我很困惑,失去了参加黑客马拉松的动力。为什么?因为我花了一些时间介绍不同的工作流程,并且了解了一些限制,这些限制使 GitHub Action 不像我一开始想的那么酷。

所有事物 GitHub 操作

在我使用 GitHub Actions 完成第一项任务并查看了个可用操作之后,我的声明很明确:all automation must go through GitHub Actions。

我想到了哪些用例?

欢迎留言

给写欢迎词给第一次投稿是一个非常有用的功能。您不仅可以使用它来说出通常的Hi,还可以与新加入者分享重要链接。在 AsyncAPI 的情况下,我想确保我们通过一个页面链接来欢迎他们,该页面解释了人们可以与AsyncAPI 社区交互的所有不同方式。

自动贴标

根据修改的文件自动对拉取请求](https://github.com/marketplace/actions/labeler)进行[标签有助于项目维护。不仅根据修改的文件进行标记,还包括其他原因,例如根据更改的大小进行标记。它加快了项目的大规模维护。

拉取请求合并

使用特定标签触发拉取请求合并是提高 GitHub 组织安全性的重要一步。为了 100% 确保您免受漏洞的影响(有人离开了您的组织,您忘记更改他的访问权限)并且您自己的错误,您不应该拥有对存储库的写入权限。写入权限应该只属于可以合并拉取请求的机器人。

💔的那一刻

添加所有这些不同的操作非常容易,尤其要感谢强大的开发者社区,他们向市场添加了许多不同的 GitHub 操作。我轻松地测试了我的 fork 上的所有更改。我在 fork 中创建了拉取请求,并证明该设置就像一个魅力。

一切都很棒,直到我开始在真实环境中使用它们。真正的环境是指一个项目,在一个组织中,它与 GitHub 上的所有其他项目一样通过分叉进行贡献。

当拉取请求来自分叉时,不支持所有这些工作流。

原因是分叉工作流中使用的默认GITHUB_TOKEN具有read-only权限。当然,您可以提供自己的秘密,例如MY_GITHUB_TOKEN,但这是没有意义的,因为自定义秘密在分叉工作流中不可用。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--suWUjYod--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/8q2kpk3f7jvs460zcccd.jpg)

这就像该功能背后的 GitHub 团队从未在开源中工作过,或者他们的安全团队比产品管理更强大。我不相信这些都是真的。毕竟是 GitHub,你有点信任这个品牌。我真的害怕原因是money。在企业级,你几乎从不使用 fork-workflow,所以基本上那些付费的人,并不需要强大的 fork 支持。

我们分手了吗?

有些关系你希望再也见不到你的前任。在这种情况下不是。我的心碎了,我很失望,但我希望我们继续做朋友。我希望这是一个临时问题,并且 GitHub 修复它,否则他们将在采用时损失很多。

我仍然会使用 GitHub Actions 来实现发布自动化,并会尽快写下它。

现在,来吧,伙计,你批评,你真是个聪明人,但这个流程有限制是有原因的,这是一个真正的安全威胁。有人可以分叉存储库,以他可以读取秘密并利用受其保护的系统的方式修改工作流程。 (一个非常可能的评论,我可以在这篇文章中得到)

这是一个有效的观点,但使用当前的 GitHub 功能很容易解决。在我之前的项目中,我使用了为 Kubernetes 构建的Prow来测试它并以非常高的规模维护社区。 Prow 还必须支持 fork-workflow。

Kubernetes test-infra 团队是如何解决安全问题的?如果拉取请求不是由组织成员创建的,它们不会触发 CI 作业。组织成员在检查拉取请求没有修改 GitHub Action 工作流程后,必须对拉取请求进行评论以触发 CI,并使用类似/ok-to-test的消息。就这么简单。

GitHub 可以在这里更进一步,将 GitHub Actions 与代码所有者功能集成。您应该能够在CODEOWNER文件中指定一组更有限的人员,他们可以批准工作流程中的更改并使用/ok-to-test触发它们。

我希望,我无意中透露了 GitHub Actions 团队已经在努力解决这个限制 😃。我真的很喜欢这个功能,也想用它来管理和支持AsyncAPI社区。我期待着用 GitHub Actions 做所有的事情。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--8qNYqwSn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/i/vfmjbwhqm19ys8wbvr3o.png)