那些有用的Github工具介绍！Action、app、workflow等

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 介绍

awesome-actions

Github Action 使用限制：

官方文档：使用限制、计费和管理
在复刻公共仓库时，默认情况下将禁用计划的工作流程。
在公共仓库中，当 60 天内未发生仓库活动时，将自动禁用计划的工作流程。

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

Github 仓库与上游自动同步

保持自己github的forks自动和上游仓库同步的
信息来源于 https://github.com/wei/pull

只同步默认分支的教程

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

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

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

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

配置 dependabot.yml

文件的配置也相对较为简单的直接，version、updates、package-ecosystem 、schedule 是必填的，还可以配置 registries 来指定私有仓库地址及认证信息。下面这个是官方示例，该示例中为 npm 和 Docker 配置了依赖自动更新，同时指定其依赖文件的地址和更新频率。有意思的是，在下面这个示例中，如果 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 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
企业用户去付费买授权

Gitlab Mirror

Github 仓库备份

最优秀的资源，大多只在短时间内出现！
平时多备份你重要的仓库，以及你使用的仓库的重要上下游仓库！

github-backup Githb
github-backup Dockerhub

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