关于 GitHub Packages 和 GitHub Actions

了解通过 GitHub Actions 工作流管理软件包的基础知识。

本文内容

持续集成工作流中的打包

打包步骤是持续集成或持续交付工作流的常见部分。在持续集成工作流结束时创建软件包可以在拉取请求代码审查期间提供帮助。

在构建和测试代码后，打包步骤可以生成可运行或可部署的工件。根据您构建的应用程序类型，此软件包可以本地下载以进行手动测试，供用户下载，或部署到暂存或生产环境。

例如，Java 项目的持续集成工作流可能会运行 mvn package 来生成 JAR 文件。或者，Node.js 应用程序的 CI 工作流可能会创建一个 Docker 容器。

现在，在审查拉取请求时，您将能够查看工作流运行并下载生成的工件。

Screenshot of the "Artifacts" section of a workflow run. The name of the artifact generated by the run, "artifact," is highlighted with a dark orange outline.

这将允许您在您的机器上运行拉取请求中的代码，这有助于调试或测试拉取请求。

发布包的工作流程

除了在持续集成工作流程中上传打包工件以进行测试外，您还可以创建工作流程来构建您的项目并将包发布到包注册表。

  • 将包发布到 GitHub Packages GitHub Packages 可以充当许多类型包的包托管服务。您可以选择与所有 GitHub 用户共享您的包，或与协作者或组织共享私有包。有关更多信息，请参阅“GitHub Packages 简介”。

    您可能希望在每次推送到默认分支时将包发布到 GitHub Packages。这将允许您项目中的开发人员始终能够轻松地运行和测试来自默认分支的最新构建，方法是从 GitHub Packages 安装它。

  • 将包发布到包注册表 对于许多项目，发布到包注册表是在发布项目的新版本时执行的。例如，生成 JAR 文件的项目可能会将新版本上传到 Maven Central 存储库。或者，.NET 项目可能会生成一个 nuget 包并将其上传到 NuGet Gallery。

    您可以通过创建一个工作流程来自动执行此操作，该工作流程在每次创建版本时将包发布到包注册表。有关更多信息，请参阅“管理存储库中的版本”。