Github Actoins 是 GitHub 推出的持续集成 (Continuous integration,简称 CI) 服务,它提供了配置非常不错的虚拟服务器环境,基于它可以进行构建、测试、打包、部署项目。是CICD的强力工具!
本文介绍几个常用的极为有用的Action工具!
GitHub Actions 是什么?
大家知道,持续集成由很多操作组成,比如抓取代码、运行测试、登录远程服务器,发布到第三方服务等等。GitHub 把这些操作就称为 actions。
很多操作在不同项目里面是类似的,完全可以共享。GitHub 注意到了这一点,想出了一个很妙的点子,允许开发者把每个操作写成独立的脚本文件,存放到代码仓库,使得其他开发者可以引用。
如果你需要某个 action,不必自己写复杂的脚本,直接引用他人写好的 action 即可,整个持续集成过程,就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。
GitHub 做了一个官方市场,可以搜索到他人提交的 actions。另外,还有一个 awesome actions 的仓库,也可以找到不少 action。
上面说了,每个 action 就是一个独立脚本,因此可以做成代码仓库,使用userName/repoName
的语法引用 action。比如,actions/setup-node
就表示github.com/actions/setup-node
这个仓库,它代表一个 action,作用是安装 Node.js。事实上,GitHub 官方的 actions 都放在 github.com/actions 里面。
更多 Github action 介绍
Github Action 使用限制:
- 官方文档:使用限制、计费和管理
- 在复刻公共仓库时,默认情况下将禁用计划的工作流程。
- 在公共仓库中,当 60 天内未发生仓库活动时,将自动禁用计划的工作流程。
- 每个仓库只能同时支持20个 workflow 并行。
- 每小时可以调用1000次 GitHub API 。
- 每个 job 最多可以执行6个小时。
- 免费版的用户最大支持20个 job 并发执行,macOS 最大只支持5个。
- 私有仓库每月累计使用时间为2000分钟,超过后$ 0.008/分钟,公共仓库则无限制。
Github 仓库与上游自动同步
保持自己github的forks自动和上游仓库同步的
只同步默认分支的教程
当上游的仓库仅有一个默认分支。或者上游仓库有两个分支,我们仅需要同步他的默认分支,其他分支对内容对我们来说无关紧要。
a) 登录自己的github账号,另开网页打开 https://github.com/wei/pull
b) 点击Pull app进行安装。
c) 安装过程中会让你选择要选择那一种方式,All repositories(就是同步已经frok的仓库以及未来fork的仓库),Only select repositories(仅选择要自己需要同步的仓库,其他fork的仓库不会被同步),根据自己需求选择,实在不知道怎么选择,就选All repositories;点击install,完成安装。
d) 后续,如果要调整1.c中的选项,打开 https://github.com/apps/pull ,点击Configure,输入github密码进入pull的相关设置。
e) 进入后,找到Repository access,根据自己的需求,重新选择:All repositories(就是同步已经frok的仓库以及未来fork的仓库),Only select repositories(仅选择要自己需要同步的仓库,其他fork的仓库不会被同步),Save后保存生效。
f) Pull app作者虽然在项目中写道keeps your forks up-to-date with upstream via automated pull requests,但当上游仓库有更改时,自己的仓库会在3个小时内完成与上游的同步,3个小时是Pull app作者说的最长时间。当然也可以通过手动触发同步上游仓库,手动触发方式:https://pull.git.ci/process/你的GitHub名字/你的仓库名字
(例如:https://pull.git.ci/process/xxxxx/test
),手动触发可能会进行人机验证,验证通过后会显示Success。
同步其他分支的教程
a) 假设你fork了上游仓库后,你fork后的地址为 https://github.com/你的仓库名字/test
,首先设置完成第1部分内容,注意在1.c步骤没有设置全部同步的,要回到1.e步,确认是否设置同步了 你的仓库名字/test
,如果没有,请添加上。
b) 在默认分支下添加一个文件。
c) 复制 .github/pull.yml
粘贴后看到以下页面,注意github前面的那个.别漏掉了。
d) 请在https://github.com/wei/pull\#advanced-setup-with-config 页复制代码,
注意:upstream处要修改为上游仓库作者名字。
e) 最终的示例如下,假设上游作者是zhangsan,所有的注意点都用红线圈出来了,保存后生效。
f) Pull app作者虽然在项目中写道keeps your forks up-to-date with upstream via automated pull requests,但当上游仓库有更改时,自己的仓库会在3个小时内完成与上游的同步,3个小时是Pull app作者说的最长时间。当然也可以通过手动触发同步上游仓库,手动触发方式:https://pull.git.ci/process/你的GitHub名字/你的仓库名字
(例如:https://pull.git.ci/process/xxxxx/test
),手动触发可能会进行人机验证,验证通过后会显示Success。具体见1.f提供的图片。
g) 本人仅测试过forks一个仓库只有2个分支的项目,如果有多个分支,不能保证是否可行,请自行测试,或者是使用本教程第3部分高级玩法。
高级玩法
当然,作者还有其他更好的项目用于同步所有分支,例如使用 GitHub actions 进行同步。请参考原作者的项目
Github 自动合并 PR
renovate
自动合并example renovate.json
mergify
- mergify
- 开源项目这个工具是免费使用的!
使用 Github Dependabot 自动更新依赖版本
通过将配置文件检入仓库,可启用 Dependabot 版本更新。 配置文件指定存储在仓库中的清单或其他包定义文件的位置。 Dependabot 使用此信息来检查过时的软件包和应用程序。 Dependabot 确定依赖项是否有新版本,它通过查看依赖的语义版本 (semver) 来决定是否应更新该版本。 对于某些软件包管理器,Dependabot 版本更新 也支持供应。 供应(或缓存)的依赖项是检入仓库中特定目录的依赖项,而不是在清单中引用的依赖项。 即使包服务器不可用,供应的依赖项在生成时也可用。 Dependabot 版本更新可以配置为检查为新版本供应的依赖项,并在必要时更新它们。
以上内容来自 GitHub 官方文档,简单的讲 Dependabot 就是一个没有感情的依赖更新机器人,在您的项目所依赖的上游软件包或应用程序发布新版本后,它会在您的 GitHub 仓库自动创建一个 PR 来更新依赖文件,并说明依赖更新内容,用户自己选择是否 merge 该 PR,效果如下图:
开启 Dependabot
开启方式比较简单,仅需将 dependabot.yml
配置文件放入仓库的 .github
目录中即可开启。之后 Dependabot 就会自动提交 PR 来更新您项目中的依赖项了。您也可以在 GitHub 页面上进行操作,在仓库页面通过 Insights
-> Dependency graph
-> Dependabot
-> Enable Dependabot
路径即可开启,之后就可以点击 Create config file
来创建配置文件了。
配置完成后,即可看到需要监控的依赖文件和上次检查更新的时间。
配置 dependabot.yml
文件的配置也相对较为简单的直接,version
、updates
、package-ecosystem
、schedule
是必填的,还可以配置 registries
来指定私有仓库地址及认证信息。下面这个是官方示例,该示例中为 npm
和 Docker
配置了依赖自动更新,同时指定其依赖文件的地址和更新频率。有意思的是,在下面这个示例中,如果 Docker 依赖项已过时很久,可能会先执行 daily
安排,直到这些依赖项达到最新状态,然后降回每周安排。更多内容,可以参考官方文档。
支持的包管理器
目前 Dependabot 支持很多包管理器,具体内容可以参考下表:
- 要用于
dependabot.yml
文件中的 YAML 值 - 支持的包管理器版本
- 是否支持私有 GitHub 仓库或注册表中的依赖项
- 是否支持供应的依赖项
Package manager | YAML value | Supported versions | Private repositories | Private registries | Vendoring |
---|---|---|---|---|---|
Bundler | bundler | v1, v2 | ✓ | ✓ | |
Cargo | cargo | v1 | ✓ | ✓ | |
Composer | composer | v1, v2 | ✓ | ✓ | |
Docker | docker | v1 | ✓ | ✓ | |
Hex | mix | v1 | ✓ | ||
elm-package | elm | v0.19 | ✓ | ✓ | |
git submodule | gitsubmodule | N/A (no version) | ✓ | ✓ | |
GitHub Actions | github-actions | N/A (no version) | ✓ | ✓ | |
Go modules | gomod | v1 | ✓ | ✓ | ✓ |
Gradle | gradle | N/A (no version) | ✓ | ✓ | |
Maven | maven | N/A (no version) | ✓ | ✓ | |
npm | npm | v6, v7 | ✓ | ✓ | |
NuGet | nuget | <= 4.8 | ✓ | ✓ | |
pip | pip | v21.1.2 | ✓ | ||
pipenv | pip | <= 2021-05-29 | ✓ | ||
pip-compile | pip | 6.1.0 | ✓ | ||
poetry | pip | v1 | ✓ | ||
Terraform | terraform | >= 0.13, <= 1.0 | ✓ | ✓ | |
yarn | npm | v1 | ✓ | ✓ |
更多内容可以参考官方文档。
Gitlab 镜像 Github
这个功能需要 gitlab ee 版本,CE版本是不支持镜像的
- 个人用户可以参考 破解Gitlab EE
- 企业用户去付费买授权
Github 仓库备份
最优秀的资源,大多只在短时间内出现!
平时多备份你重要的仓库,以及你使用的仓库的重要上下游仓库!
自动翻译
实例 GitHub Action https://github.com/walinejs/waline/blob/main/.github/workflows/issue-translator.yml
源码 https://github.com/lizheming/issues-translate-action 基于 https://github.com/dromara/issues-translate-action
后记
github action 太多强大,这里仅仅只能介绍一点点,有太多好东西了,太多宝藏值得去挖掘!
这就是开源的力量!在被大公司白嫖的同时,创造了无与伦比的社区生态!
参考&致谢
系列教程
Devops系列
- 自建全套开源Devops开发系统
- Git介绍以及分支模型图解
- 三万字无坑搭建基于Docker+K8S+GitLab/SVN+Jenkins+Harbor持续集成交付环境
- DevOps系列—【Jenkinsfile+Dockerfile+nginx+vue】
- 项目开发管理工具推荐
- Gitlab的安装及使用教程完全版
- Gitlab的安装及使用
- 那些有用的Github工具介绍!Action、app、workflow等
Gitbook使用系列
- GitBook+GitLab撰写发布技术文档-Part1:GitBook篇
- GitBook+GitLab撰写发布技术文档-Part2:GitLab篇
- 自己动手制作电子书的最佳方式(支持PDF、ePub、mobi等格式)