Github Action Day1:CI/CD 触发器

这是我的 Github Action Advent Calendar 第一天的全部内容,如果您想要了解更多已经发布的 tips 信息,查看此处的 索引

Github Action 是一个独特的系统:它提供构建 CI/CD 什么是持续集成(CI)/持续部署(CD)? 操作的功能 ,具有构建以及测试 pull requests 并将其合并到主分支上的能能力,但它却比普通的构建 (build) 系统更加强大。它被集成在 Github中, 可以在您的 Github 仓库 发生任何事件时 运行对应的工作流,如在创建一个 release 或者 issue 被提交时。

在接下来的一个月中,我将更多地围绕仓库中的自动化场景进行描述,了解这些灵活性的存在可以帮助你理解如何使用 CI/CD 构建(build)设置。

Github Action 允许你定义一个trigger(触发器) 控制你的工作流何时运行。当某个action 捕获到对应的 trigger(触发器)事件在某个仓库发生时,对应的工作流也将进入运行的队列。

Translate Note:

触发器类似于我们接触的事件,当一个事件发生才会触发对应的工作流,所有的可触发事件在 这里 可以查阅

对于 CI/CD 类的工作流,我更喜欢使用 pushpull_request 触发器,而且将其限制在我感兴趣的分支中。

示例如下:

on:
push: #监听push事件发生
branches:
- master #指定push到的分支为master分支
pull_request: #监听pull_request事件发生
branches:
- master #指定在master分支上创建 pull_request

在你的仓库 master 分支上发生任何改变时,该触发器都会启动并运行对应的工作流(即使触发器的名字为 push,但在你运行 git push 命令或者合并 一个 pull request 进入 master 分支时其实都会运行)。此外,当在 master 分支上创建一个新的 pull request 时:

image-20210803210016040

该工作流也会运行,而且会显示对该 pull request 的验证信息。

image-20210803210321333

如果你熟悉 yaml 语法的话 ,可以注意到这些分支接受数组。因此,你可以很方便地设置一个运行在多个分支上的工作流,这可以帮助你维护不同的 release 追踪,例如:

on:
push:
branches:
- master
- 'releases/**'
pull_request:
branches:
- master
- 'releases/**'

上面的触发器设置表示:当在 master 分支或者 某个以 releases/ 为开头的分支 上创建了某个 pull request 时,该 workflow 会运行。

通过 Github Actionpushpull_request 触发器使得用户可以很容易就能设置 CI/CD 风格的工作流来通过验证pull requests,并将它们合并到主分支上。

什么是持续集成(CI)/持续部署(CD)?

GitHub Actions 的工作流程语法 - GitHub Docs

触发工作流程的事件 - GitHub Docs