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,解决方案也很多。
我们程序员在学习中,能够体会到本质,举一反三,便是最好的状态。