发布和维护操作

简介

创建操作后，您需要继续发布新功能，同时处理社区贡献。 本教程介绍了一个示例过程，您可以遵循该过程在开源中发布和维护操作。 示例：

• 利用 GitHub Actions 实现持续集成、依赖项更新、版本管理和任务自动化。
• 通过自动化测试和构建徽章提供信心。
• 指示如何使用操作，理想情况下，作为更广泛的工作流程的一部分。
• 表明您欢迎哪种类型的社区贡献。 （例如，议题、拉取请求或漏洞报告。）

有关此过程的应用示例，请参阅 actions/javascript-action。

开发和发布操作

在本节中，我们将讨论开发和发布操作的示例流程，并演示如何使用 GitHub Actions 自动执行该过程。

关于 JavaScript 操作

JavaScript 操作是具有元数据的 Node.js 存储库。 但是，与传统的 Node.js 项目相比，JavaScript 操作具有其他属性：

• Dependent 包与代码一起提交，通常采用编译和缩小的形式。 这意味着自动化构建和安全的社区贡献非常重要。

• 许多操作都使用 GitHub 的 API 和第三方 API，因此我们鼓励进行强大的端到端测试。

设置 GitHub Actions 工作流程

要在下一节中支持开发人员流程，请将两个 GitHub Actions 工作流程添加到存储库中：

1. 添加在将提交推送到功能分支或 main 或者创建拉取请求时触发的工作流。 配置工作流程以运行单元和集成测试。 有关示例，请参阅此工作流。
2. 添加在发布或编辑发布时触发的工作流程。 配置工作流程以确保语义标记已就位。 可以使用 JasonEtco/build-and-tag-action 等操作来编译和捆绑 JavaScript 和元数据文件，并强制推送语义主要、次要和补丁标记。 有关语义标记的详细信息，请参阅“关于语义版本控制”。

示例开发者流程

下面是一个示例过程，你可以遵循该过程来自动运行测试、创建发行版，然后发布你的操作。

1. 在每个 GitHub 流程的分支中执行功能工作。 有关详细信息，请参阅“GitHub 流”。

   • 每当将提交推送到功能分支时，测试工作流程将自动运行测试。

2. 创建对 main 分支的拉取请求以启动讨论和审查，并在准备就绪时合并。

   • 当从分支或复刻打开拉取请求时，测试工作流将再次运行测试，这次是合并提交。

   • 注意：出于安全原因，由分支中的 pull_request 触发的工作流具有受限的 GITHUB_TOKEN 权限，并且无权访问机密。 如果拉取请求时触发的测试或其他工作流需要访问机密，请考虑使用不同的事件，例如手动触发器或 pull_request_target。 有关详细信息，请参阅“触发工作流的事件”。

3. 创建语义标记的版本。 有关详细信息，请参阅“管理仓库中的发行版”。

   • 发布或编辑版本时，发行版工作流程将自动负责编译和调整标记。

   • 建议使用语义版本化的标记（例如 v1.1.3）创建版本，并让主要 (v1) 和次要 (v1.1) 标记与最新的相应提交保持同步。 有关详细信息，请参阅“关于自定义操作”和“关于语义版本控制”。

结果

与其他一些自动发布管理策略不同，此过程有意不将依赖项提交到 main 分支，而仅提交已标记的版本。 这样做，可以鼓励操作用户引用已命名的标记或 sha，并且通过在发布过程中自己执行构建来帮助确保第三方拉取请求的安全性。

使用语义发行版意味着操作的用户可以将其工作流程固定到某个版本，并且知道他们可能会继续接收最新的稳定、不间断功能，具体取决于他们的舒适度。

与社区合作

GitHub Enterprise Server 提供工具和指南，帮助您与开源社区合作。 以下是我们建议为健康的双向通信设置的一些工具。 通过向社区提供以下信号，您可以鼓励其他人使用、修改和参与您的操作：

• 维护其中包含大量用法示例和指导的 README。 有关详细信息，请参阅“关于自述文件”。
• 在 README 文件中添加工作流状态徽章。 有关详细信息，请参阅“添加工作流状态徽章”。 若要了解可添加的其他徽章，另请访问 shields.io。
• 利用 actions/stale 等操作使问题保持最新。

其他阅读材料

采用类似模式的示例包括：

• github/super-linter
• octokit/request-action
• actions/javascript-action