在 GitHub 操作工作流中重用作业

Question

我正在将管道从 Circle CI 迁移到 Github Actions 并且发现我只能运行一次作业而不是创建作业，然后从工作流部分调用它，这使得可以多次调用作业而无需复制该作业中的命令/脚本。

我的管道将代码推送到三个环境，然后对每个环境运行一次灯塔扫描。 在循环 ci 中，我有 1 份工作将代码推送到我的环境，还有 1 份工作来运行灯塔。 然后从我的工作流部分，我只调用了 3 次作业，将 env 作为参数传递。 我是否遗漏了什么，或者在 github 动作中没有办法做到这一点？ 我是否只需要在每个工作中写出我的命令 3 次？

Answer 1

GitHub Actions 中有 3 种主要的代码重用方法：

重用工作流程

显而易见的选择是使用“可重用工作流程”功能，该功能允许您将一些步骤提取到单独的“可重用”工作流程中，并将此工作流程称为其他工作流程中的作业。

要点：

• 可重用工作流不能调用其他可重用工作流。
• 调用可重用工作流的任何作业都不支持strategy属性。
• 环境变量和秘密不会被继承。
• 如果您需要在一项工作中提取和重用多个步骤，这并不方便。
• 由于它作为单独的作业运行，因此您必须使用构建工件在可重用工作流和主工作流之间共享文件。
• 您可以以同步或异步方式调用可重用工作流（通过使用needs键的作业排序来管理它）。
• 可重用的工作流可以定义从执行步骤中提取输出/结果的输出。 它们可以很容易地用于将数据传递给“主”工作流。

分派的工作流

GitHub 给我们的另一种可能性是可以触发工作流运行的workflow_dispatch事件。 简而言之，您可以手动或通过 GitHub API 触发工作流并提供其输入。

Marketplace 上有一些可用的操作，可让您触发“已调度”工作流程作为“主要”工作流程的一个步骤。

其中一些还允许以同步方式执行此操作（等到分派的工作流完成）。 值得一提的是，这个特性是通过轮询 repo 工作流的状态来实现的，这不是很可靠，尤其是在并发环境中。 此外，它受 GitHub API 使用限制的限制，因此在查找已调度工作流的状态时会有延迟。

外卖

• 您可以有多个嵌套调用，从另一个触发的工作流触发一个工作流。 如果做的不小心，可能会导致死循环。
• 您需要具有“工作流程”权限的特殊令牌； 你通常的secrets.GITHUB_TOKEN不允许你调度工作流。
• 您可以在一个作业中触发多个分派的工作流。
• 没有简单的方法可以将一些数据从分派的工作流中恢复到主要的工作流中。
• 在“一劳永逸”的情况下效果更好。 等待分派的工作流完成有一些限制。
• 您可以观察已调度的工作流运行并手动取消它们。

复合动作

在这种方法中，我们将步骤提取到不同的复合操作中，该操作可以位于相同或单独的存储库中。

从您的“主要”工作流程来看，它看起来像一个通常的操作（一个步骤），但在内部它由多个步骤组成，每个步骤都可以调用自己的操作。

要点：

• 支持嵌套：复合动作的每一步都可以使用另一个复合动作。
• 内部步骤运行的不良可视化：在“主要”工作流程中，它显示为通常的步骤运行。 在原始日志中，您可以找到内部步骤执行的详细信息，但看起来不太友好。
• 与父作业共享环境变量，但不共享机密，应通过输入显式传递。
• 支持输入和输出。 输出是从内部步骤的输出/结果准备的，并且可以很容易地用于将数据从复合操作传递到“主”工作流。
• 复合动作在“主”工作流的作业中运行。 由于它们共享一个公共文件系统，因此无需使用构建工件将文件从复合操作传输到“主”工作流。
• 您不能在复合操作中使用continue-on-error选项。

来源：我的“DRY：在 GitHub Actions 中重用代码”文章

Answer 2

我目前在同一条船上，刚刚找到了答案。 您正在寻找一个Composite Action ，正如this answer中所建议的那样。

Answer 3

可重用工作流不能调用其他可重用工作流。

实际上，自 2022 年 8 月以来，他们可以：

GitHub 操作：改进可重用工作流

现在可以从矩阵和其他可重用工作流中调用可重用工作流。

您现在可以嵌套多达 4 个级别的可重用工作流，从而为您提供更大的灵活性和更好的代码重用。

从矩阵调用可重用的工作流允许您创建更丰富的参数化构建和部署。

了解有关嵌套可重用工作流的更多信息。

了解有关使用矩阵策略的可重用工作流的更多信息。