Github Actions: submodule 下公私有仓库授权和通信
先来看一个场景
在 Github 有一个项目 ，简要的结构如下
简单解释一下这张图：
这个项目，由一个公有项目和一个私有项目组成，通过 git submodule 2者之间链接在了一起。
它们都有很多的 Actions , 比如:
-
deploy负责发布任务。 -
push负责主动推送link给各大搜索引擎。 -
sync负责解析markdown并通过md5摘要比对，同步修改到远程数据库里。 -
action trigger负责远程触发其他仓库的action。
但是，由图上可知， Actions 是分散在 2 个仓库里的，一个公有，一个私有。它们这些 Actions 如何进行权限验证和通信呢？
在这里, 我主要通过图中橙色那两个箭头 submodule, remote ，
通过他们对 deploy 这个 action 的影响，来和大家简单的聊聊解决方案。
actions/checkout
checkout 想必是用的最多的 action 之一了
有了它，编写的 workflow 才有权限去访问我们的仓库。
我们往往使用的时候，就写那么一行
- uses: actions/checkout@v2
这一行的默认配置，使用是获取当前 $GITHUB_WORKSPACE 下的仓库文件。
显然它的功能不仅如此，它也可以获取任意仓库，只要我们给它提供授权。
访问私有仓库
由图上可知，我们公有仓库里，附加了一个私有仓库作为子模块。
这时候使用 checkout 的默认授权，能够获取私有子模块仓库的代码吗？
显然是不能的，如图所示：
[图片上传失败...(image-130ea3-1631696944920)]
所以，我们要给 checkout action 进行授权，让它有权限去获取 private submodule
Q: 怎么授权？
A: PAT (personal access token)
添加步骤：Settings -> Developer settings -> Personal access tokens -> Generate new token
同时确保 PAT 有 Full control of private repositories 的能力。
[图片上传失败...(image-849d89-1631696944920)]
在获取 token 之后，就可以:
- uses: actions/checkout@v2
with:
# Default: ${{ github.token }} ,传参给它更高权限的 token
token: ${{ secrets.PERSONAL_TOKEN }}
# 把子模块打开
submodules: 'true'
于是就能在 public 的action 里轻松的访问 private 的 repo 了。
[图片上传失败...(image-ee6f80-1631696944920)]
Workflow dispatch event
下一个问题：
Q: 怎么在私有的B仓库里，触发公有的A仓库的 Action 呢？
A: REST+PAT 授权，远程调用触发
这个大家都非常熟悉了，方法上无非是把 token 作为授权，去调用一个接口，在传参校验成功之后，action 就跑起来了，大家看到的那些 openapi,云厂商的 SDK 都是这么做的。
Github 也是如此, 上图。
声明可触发
首先需要在 workflows 文件里，加一行：
on:
workflow_dispatch:
代表此 action 可被 workflow event 触发。
接着就可以进行下一步。
RESTful API
[图片上传失败...(image-5aeeca-1631696944920)]
图上的参数暴露了一切 , 英文已经解释的非常清楚了。
那么我们触发一个任意仓库里的 action 就可以这么写：
// 注: 偷懒可以直接使用 `Octokit`
const octokit = new Octokit({
auth: GITHUB_PERSONAL_TOKEN,
timeZone: 'Asia/Shanghai',
baseUrl: 'https://api.github.com'
})
await octokit.rest.actions.createWorkflowDispatch({
owner: 'sonofmagic',
ref: 'dev',
repo: 'icebreaker.top',
workflow_id: 'blog-deployer.yml'
// inputs: {
// hello: 'world'
// }
})
其中 inputs 这个可选参数，是可以用作 action yml文件本身的逻辑判断的。
这里展示一下它的用法和校验：
name: Manually triggered workflow
on:
workflow_dispatch:
inputs:
name:
description: 'Person to greet'
required: true
default: 'Mona the Octocat'
home:
description: 'location'
required: false
default: 'The Octoverse'
jobs:
say_hello:
runs-on: ubuntu-latest
steps:
- run: |
echo "Hello ${{ github.event.inputs.name }}!"
echo "- in ${{ github.event.inputs.home }}!"
看到上面这段代码，是不是瞬间理解了，inputs 参数是什么？怎么用？
当然除了 Workflow dispatch event 这种触发方式，还有 Repository dispatch event 不过，那个值得以后单独聊。
后记
想搞 monorepo : lerna, workspace ,submodule 等等解决方案很多。
CI/CD 的解决方案也很多，各种写法，各种文档，API 不尽相同。
写前端，客户端，app，解决方案也很多。
我们程序员在学习中，能够体会到本质，举一反三，便是最好的状态。
附录
源码
RESTful API官方链接