【问题标题】:Should actions be stored in a separate repo or nested in another操作应该存储在单独的存储库中还是嵌套在另一个存储库中
【发布时间】:2021-05-12 10:18:23
【问题描述】:

创建 Github Action 的最佳实践是什么?

似乎大致有三种方法


一个 repo = 一个 Action

these examples 我清楚地得出 1 个操作 = 1 个 repo。

action-repo
  action.yml
  ...

有用法:

uses: org/action-repo@tag

带有嵌套动作的“正常”回购

Some 倾向于像这样将操作添加到他们的仓库中:

repo
  github-action
    action.yml
    ...

可能还有不止一个动作。这已经提供了更长的导入,例如:

uses: org/repo/github-action@tag

具有嵌套/隐藏操作的“普通”回购

这是我见过的最特殊的情况:

repo
  .github
    actions
      action1
        action.yml
        ...
      action2
        action.yml
        ...

这种设置导致在使用动作时出现一些奇怪的导入,例如

uses: org/repo/.github/actions/action1@tag

有人看过这方面的官方文档吗?

【问题讨论】:

  • 我见过大约三种模式:单独的 repo 仅用于操作(如在actions org 中); repos 有多个动作,使用时必须指定整个路径,版本控制很尴尬; repo 主要用于工具,但兼作操作(如github.com/mikefarah/yq)。您的示例是第二种情况的特例,但是当它应该在其他地方使用时将操作隐藏到 .github 中似乎很奇怪。不过,我觉得它在一天结束时是基于意见的。
  • 我明白了,有道理。我将更新我的问题以包含您的意见。一个问题仍然存在,“最佳实践”(除了意见)在哪里?因为正如你所说,例如关于版本控制,你显然有一个缺点。

标签: github-actions


【解决方案1】:

进入 GHA 两周,看到几十个存储库,我敢于自己回答我的问题。

正如最初的 cmets 所建议的,您选择的方法主要取决于您的用例。

让我也重复使用该评论的一部分来完成我的总结(任何人都可以随意发表评论,我会将论点纳入我的列表)。

方法

org/action-repo

上面称为“1 次行动 = 1 次回购”

  • ➕  当然,最常见的标准,许多“同类最佳”操作(例如结帐、setup-xyz 等)都使用这种方法
  • ➕  透明版本控制
  • ➕  直接uses(无嵌套路径)
  • ➕  遵循 UNIX 哲学,做好一件事
  • ➕  易于记录、遇到问题和拉取请求,仅针对您的操作

  • ➖  其他回购

当您希望自己的行动被大型社区采用或您只是觉得“公众需要”时,这是一种合适的方法。

org/repo/action

上面称为嵌套动作

➕➖  上面的对比正好相反。

这种方法主要适用于维护一些您只是想在项目中随意提供的较小操作。我们现在在我们的案例中使用它来将一些特定于单一存储库的操作累积到一个地点。

org/repo/.github/action(s)

这种方法无疑是最特殊的一种,也是第二种方法的派生。一般来说,它没有真正的用例 - 有可能变出一个,例如在 mono-repo 中将所有操作抽象到 .github 文件夹中以收集它们。另一方面,您也可以在org/repo/action(s) 中这样做。

随时通过评论来完成我的列表。

【讨论】:

    【解决方案2】:

    您可以随时参考documentation

    如果您正在开发供其他人使用的操作,我们建议您将操作保存在自己的存储库中,而不是将其与其他应用程序代码捆绑在一起。这使您可以像任何其他软件一样对操作进行版本控制、跟踪和发布。

    将操作存储在自己的存储库中可以让 GitHub 社区更轻松地发现操作,缩小开发人员修复问题和扩展操作的代码库范围,并将操作的版本控制与其他应用程序代码的版本控制分离.

    如果您正在构建不打算向公众提供的操作,您可以将操作的文件存储在存储库中的任何位置。如果您计划将操作、工作流和应用程序代码组合在一个存储库中,我们建议将操作存储在 .github 目录中。例如,.github/actions/action-a 和 .github/actions/action-b。

    【讨论】:

      猜你喜欢
      • 2010-09-12
      • 1970-01-01
      • 2023-03-27
      • 1970-01-01
      • 2010-11-24
      • 1970-01-01
      • 2012-03-10
      • 2016-07-14
      • 1970-01-01
      相关资源
      最近更新 更多