跳至主要内容

关于使用 GitHub Actions 打包

您可以在 GitHub Actions 中设置工作流以生成包并将其上传到 GitHub Packages 或其他包托管提供商。

持续集成工作流中的打包

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

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

例如,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。

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

进一步阅读