Github Actoins 是 GitHub 推出的持续集成 (Con­tin­u­ous in­te­gra­tion,简称 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 介绍

awesome-actions

Github Action 使用限制:

  • 每个仓库只能同时支持20个 workflow 并行。
  • 每小时可以调用1000次 GitHub API 。
  • 每个 job 最多可以执行6个小时。
  • 免费版的用户最大支持20个 job 并发执行,macOS 最大只支持5个。
  • 私有仓库每月累计使用时间为2000分钟,超过后$ 0.008/分钟,公共仓库则无限制。

Github 仓库与上游自动同步

保持自己github的forks自动和上游仓库同步的

信息来源于 https://github.com/wei/pull

只同步默认分支的教程

当上游的仓库仅有一个默认分支。或者上游仓库有两个分支,我们仅需要同步他的默认分支,其他分支对内容对我们来说无关紧要。

git1.jpg

a) 登录自己的github账号,另开网页打开 https://github.com/wei/pull

b) 点击Pull app进行安装。

git2.jpg

c) 安装过程中会让你选择要选择那一种方式,All repositories(就是同步已经frok的仓库以及未来fork的仓库),Only select repositories(仅选择要自己需要同步的仓库,其他fork的仓库不会被同步),根据自己需求选择,实在不知道怎么选择,就选All repositories;点击install,完成安装。

git3.jpg

d) 后续,如果要调整1.c中的选项,打开 https://github.com/apps/pull ,点击Configure,输入github密码进入pull的相关设置。

git4.jpg

e) 进入后,找到Repository access,根据自己的需求,重新选择:All repositories(就是同步已经frok的仓库以及未来fork的仓库),Only select repositories(仅选择要自己需要同步的仓库,其他fork的仓库不会被同步),Save后保存生效。

git5.jpg

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。

git12.jpg

git13.jpg

同步其他分支的教程

git8.jpg

a) 假设你fork了上游仓库后,你fork后的地址为 https://github.com/你的仓库名字/test ,首先设置完成第1部分内容,注意在1.c步骤没有设置全部同步的,要回到1.e步,确认是否设置同步了 你的仓库名字/test,如果没有,请添加上。

git9.jpg

b) 在默认分支下添加一个文件。

git10.jpg

c) 复制 .github/pull.yml 粘贴后看到以下页面,注意github前面的那个.别漏掉了。

git11.jpg

d) 请在https://github.com/wei/pull#advanced-setup-with-config 页复制代码,

注意:upstream处要修改为上游仓库作者名字。

git12.jpg

git13.jpg

e) 最终的示例如下,假设上游作者是zhangsan,所有的注意点都用红线圈出来了,保存后生效。

git14.jpg

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

renovate free

自动合并example renovate.json

{
  "extends": ["config:base"],
  "assignees": ["17lai"],
  "separateMinorPatch": true,
  "packageRules": [
    {
      "updateTypes": ["minor", "patch"],
      "automerge": true,
      "automergeType": "branch"
    }
  ]
}

mergify

  • mergify
  • 开源项目这个工具是免费使用的!

mergify free for open source

使用 Github Dependabot 自动更新依赖版本

通过将配置文件检入仓库,可启用 Dependabot 版本更新。 配置文件指定存储在仓库中的清单或其他包定义文件的位置。 Dependabot 使用此信息来检查过时的软件包和应用程序。 Dependabot 确定依赖项是否有新版本,它通过查看依赖的语义版本 (semver) 来决定是否应更新该版本。 对于某些软件包管理器,Dependabot 版本更新 也支持供应。 供应(或缓存)的依赖项是检入仓库中特定目录的依赖项,而不是在清单中引用的依赖项。 即使包服务器不可用,供应的依赖项在生成时也可用。 Dependabot 版本更新可以配置为检查为新版本供应的依赖项,并在必要时更新它们。

以上内容来自 GitHub 官方文档,简单的讲 Dependabot 就是一个没有感情的依赖更新机器人,在您的项目所依赖的上游软件包或应用程序发布新版本后,它会在您的 GitHub 仓库自动创建一个 PR 来更新依赖文件,并说明依赖更新内容,用户自己选择是否 merge 该 PR,效果如下图:

Dependabot PR

开启 Dependabot

开启方式比较简单,仅需将 dependabot.yml 配置文件放入仓库的 .github 目录中即可开启。之后 Dependabot 就会自动提交 PR 来更新您项目中的依赖项了。您也可以在 GitHub 页面上进行操作,在仓库页面通过 Insights -> Dependency graph -> Dependabot -> Enable Dependabot 路径即可开启,之后就可以点击 Create config file 来创建配置文件了。

开启 Dependabot

配置完成后,即可看到需要监控的依赖文件和上次检查更新的时间。

img

配置 dependabot.yml

文件的配置也相对较为简单的直接,versionupdatespackage-ecosystemschedule 是必填的,还可以配置 registries 来指定私有仓库地址及认证信息。下面这个是官方示例,该示例中为 npmDocker 配置了依赖自动更新,同时指定其依赖文件的地址和更新频率。有意思的是,在下面这个示例中,如果 Docker 依赖项已过时很久,可能会先执行 daily 安排,直到这些依赖项达到最新状态,然后降回每周安排。更多内容,可以参考官方文档

# Basic dependabot.yml file with
# minimum configuration for two package managers

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    # Look for `package.json` and `lock` files in the `root` directory
    directory: "/"
    # Check the npm registry for updates every day (weekdays)
    schedule:
      interval: "daily"

  # Enable version updates for Docker
  - package-ecosystem: "docker"
    # Look for a `Dockerfile` in the `root` directory
    directory: "/"
    # Check for updates once a week
    schedule:
      interval: "weekly"

支持的包管理器

目前 Dependabot 支持很多包管理器,具体内容可以参考下表:

  • 要用于 dependabot.yml 文件中的 YAML 值
  • 支持的包管理器版本
  • 是否支持私有 GitHub 仓库或注册表中的依赖项
  • 是否支持供应的依赖项
Package managerYAML valueSupported versionsPrivate repositoriesPrivate registriesVendoring
Bundlerbundlerv1, v2
Cargocargov1
Composercomposerv1, v2
Dockerdockerv1
Hexmixv1
elm-packageelmv0.19
git submodulegitsubmoduleN/A (no version)
GitHub Actionsgithub-actionsN/A (no version)
Go modulesgomodv1
GradlegradleN/A (no version)
MavenmavenN/A (no version)
npmnpmv6, v7
NuGetnuget<= 4.8
pippipv21.1.2
pipenvpip<= 2021-05-29
pip-compilepip6.1.0
poetrypipv1
Terraformterraform>= 0.13, <= 1.0
yarnnpmv1

更多内容可以参考官方文档

Gitlab 镜像 Github

这个功能需要 gitlab ee 版本,CE版本是不支持镜像的

Gitlab Mirror

Github 仓库备份

最优秀的资源,大多只在短时间内出现!

平时多备份你重要的仓库,以及你使用的仓库的重要上下游仓库!

githubback:
  image: lnxd/github-backup
  container_name: "githubback"
  hostname: githubback
  # ports:
    # - "80:80"
  volumes:
    - "${USERDIR}/githubback/data:/home/docker/backups:rw"
  env_file:
    - .env
  environment:
    - HTTP_PROXY=http://[ip]:[port]
    - HTTPS_PROXY=http://[ip]:[port]
  restart: always

后记

github action 太多强大,这里仅仅只能介绍一点点,有太多好东西了,太多宝藏值得去挖掘!

这就是开源的力量!在被大公司白嫖的同时,创造了无与伦比的社区生态!

参考&致谢

系列教程

全部文章RSS订阅

Devops系列

Devops 分类 RSS 订阅

Gitbook使用系列

Gitbook分类RSS订阅

Gitlab 使用系列

Gitlab RSS 分类订阅


文章作者: 夜法之书
版权声明: 本博客所有文章除特別声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 夜法之书 !
评论
 上一篇

阅读全文

关于普朗克概率的的讨论
关于普朗克概率的的讨论 关于普朗克概率的的讨论
存在最小的普朗克时间和普朗克长度,那么,在真实世界中,是否会存在一个“普朗克概率”?这个最小概率应该是存在的!
2022-10-06
下一篇 

阅读全文

Potplayer终极优化教程实现PC视频播放最强画质
Potplayer终极优化教程实现PC视频播放最强画质 Potplayer终极优化教程实现PC视频播放最强画质
视频播放器使用还是有不少细节需要注意的。本文介绍流行播放器Potplayer 配置方法,搭配 Emby 和 embyLaunchPotplayer 使用的效果更佳!
2022-09-06
  目录