GitHub在2019年5月宣布发布Package Registry服务。 此后，已经在8月宣布了对Actions中CI / CD的支持。
在本文中，我将告诉您什么是服务，以及如何在GitHub上的一个小型宠物项目的示例中使用这些服务。
这些是什么服务？
GitHub Actions是一个平台，可让您管理软件生命周期，其源代码托管在GitHub上。 实际上，TravisCI，CircleCI和许多其他免费的CI / CD平台在Actions方面获得了新的竞争对手。
GitHub Package Registry是工件的中央存储库；当前支持五种不同类型的工件。
动作中受支持的工件类型
这是将所有工件放在一起的便利机会，因为并非总是建议部署Nexus或Artifactory服务器。
GitHub与GitLab越来越相似，并且在某个地方它已经超越了对手，例如，GitLab 尚不支持NuGet包和Ruby gem。 实际上，如果更早地进行开源项目，则必须将外部集成连接到GitHub，那么现在所有的问题都集中在一个篮子里。 在这里，让每个人决定它的好坏，但至少很方便。
怎么尝试？
目前这两种服务都处于beta模式，您可以在这些 页面上注册进行beta测试。
从其他服务的迁移非常简单，我将几个宠物项目分别从TravisCI和DockerHub迁移到了Actions和Package Registry。
我将在一个示例中向您展示它的外观。 该项目是最常见的，我在本文中对此进行了介绍。 没什么复杂的，通常的LaTeX代码，借助其收集的工件（2个PDF文件），将它们发布在GitHub版本中。 为了不下载一堆LaTeX软件包，我编写了一个Dockerfile，以便您可以在任何操作系统下方便地工作。
包注册表
为了开始使用Package Registry而不是DockerHub，您只需要执行两个简单步骤。
在GitHub设置中创建一个令牌（令牌必须具有读写工件权限）。
代币创建页面
然后，我们可以使用创建的令牌进行身份验证并推送工件，这很简单：
docker login docker.pkg.github.com --username amet13 docker tag docker-latex:0.0.1 docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1 docker push docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1
请注意，我在GitHub上小写了我的昵称，否则您将从Docker得到错误：
Error parsing reference: "docker.pkg.github.com/Amet13/master-thesis/docker-latex:0.0.1" is not a valid repository/tag: invalid reference format: repository name must be lowercase
这是GitHub Web界面中的外观：
Docker映像的软件包注册表页面
除了下载最新映像的说明之外，还提供下载统计信息，还可以通过Web界面下载单独的Docker层，还提供映像下载历史记录。
动作
动作稍微复杂一点，但是对于那些曾经使用过任何其他CI / CD系统的人来说，这并不难理解。 尽管以前使用 HCL，但声明式YAML描述了“操作”中的配置。
一些基本概念（我不会故意翻译这些定义，我认为这里很清楚）：
- 工作流程-管理存储库的软件生命周期（构建，测试，打包，发布，部署）的过程
- 工作流文件-描述工作流的文件，位于目录
.github/workflows/存储库的根目录中。 - Job是工作流的每一次运行，都会触发Job，在某个时间点可以启动很多Job
- 步骤-每个作业都有一个步骤，您可以在每个步骤运行命令或操作
- Action-由某人编写的“插件”，在awesome-actions存储库中可以找到许多Action的列表
- 虚拟环境-作业运行的环境（实际上，它是Windows，macOS或Linux上的虚拟机）
- Runner是用于启动Job的已部署环境，一次只能在Runner上运行一个Job
- 事件-触发工作流的事件，例如，推，拉请求，Webhook，Cron作业等。
- 工件-工件（二进制文件，图像，日志等）
这就是工作流程中的“工作列表”页面。
限制和禁止：
- 每个存储库20个工作流
- 每小时1000个API请求，用于存储库中的所有操作
- 最长工作时间-6小时
- 20个作业可以在存储库中并行工作（对于所有工作流程）
- 禁止将操作用于加密货币挖掘和无服务器计算
此链接提供了最新文档。
这是约伯记之一的日志
例子
让我们回到示例， 这是我的配置，我们将分部分对其进行详细分析。
为工作流指定一个名称，并描述应该在哪个触发器上触发（ 文档中描述了所有触发器的列表）：
name: master-thesis on: [push]
在哪个虚拟环境上运行作业：
jobs: build: # ubuntu-latest, ubuntu-18.04, or ubuntu-16.04 # windows-latest, windows-2019, or windows-2016 # macOS-latest or macOS-10.14 runs-on: ubuntu-latest
第一步，在name:指定Step的名称（可选），在uses:我们要使用哪个Action，在这种情况下，请克隆存储库：
steps: - name: Checkout repo uses: actions/checkout@v1
在下一步中，我们不使用Action，而仅使用我们的一组命令登录到Package Registry，收集Docker映像并将其推入映像存储库。 在env:块中env:设置环境变量，我们从秘密中获取其中之一：
- name: Build docker image and push it to the registry env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} DOCKER_IMAGE_ORIGIN: "docker.pkg.github.com/amet13/master-thesis/docker-latex" run: | # Pull submodules git submodule init git submodule update --remote # Login to GitHub Packages and build Docker image docker login docker.pkg.github.com -u amet13 -p ${GITHUB_TOKEN} docker pull ${DOCKER_IMAGE_ORIGIN}:latest docker build -t ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} . # Generate PDF artifacts docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "latexmk -xelatex -synctex=1 -jobname=master-thesis main.tex" docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "cd presentation/ && latexmk -xelatex -synctex=1 -jobname=presentation main.tex" # Publish Docker image to GitHub Packages (with latest tag) docker tag ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} ${DOCKER_IMAGE_ORIGIN}:latest docker push ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} docker push ${DOCKER_IMAGE_ORIGIN}:latest
我确信不久的将来会出现一个Action，它将自动标记和推送图像，而不是手动编写Docker命令。
添加包含github令牌的机密
构建PDF之后的下一步是在GitHub上创建一个发行版，并将收集的工件包括在此发行版中。 为了自动创建发行版，我们使用了第三方 Action，其中在if:块中，您可以指定启动步骤的条件-仅在创建标记时：
- name: Create GitHub release with artifacts uses: softprops/action-gh-release@v1 if: startsWith(github.ref, 'refs/tags/') with: files: | master-thesis.pdf presentation/presentation.pdf name: "Build ${GITHUB_SHA}" env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
总结
尽管处于测试版状态，但两种服务都能正常运行，我敢肯定，很多事情都将完成。
在某些时候可能很不方便，没有全局变量，但是可以用拐杖完成。
我喜欢GitHub放弃HCL而使用YAML的方法。 我还喜欢对许多类型主机的支持，这些主机的限制非常小（目前），让我们看看它是如何进行的。 通常，对于GitHub上公共存储库中的简单管道，这样的组合将非常有效。
本文的翻译已经在媒体上进行 。