Github Actions: submodule 下公私有仓库授权和通信

Github Actions: submodule 下公私有仓库授权和通信_第1张图片

先来看一个场景

在 Github 有一个项目 ,简要的结构如下

Github Actions: submodule 下公私有仓库授权和通信_第2张图片结构

简单解释一下这张图:

这个项目,由一个公有项目和一个私有项目组成,通过 git submodule 2者之间链接在了一起。

它们都有很多的 Actions , 比如:

  • deploy 负责发布任务。
  • push 负责主动推送link给各大搜索引擎。
  • sync 负责解析 markdown 并通过 md5 摘要比对,同步修改到远程数据库里。
  • action trigger 负责远程触发其他仓库的 action

但是,由图上可知, Actions 是分散在 2 个仓库里的,一个公有,一个私有。它们这些 Actions 如何进行权限验证和通信呢?

在这里, 我主要通过图中橙色那两个箭头 submoduleremote ,

通过他们对 deploy 这个 action 的影响,来和大家简单的聊聊解决方案。

actions/checkout

checkout 想必是用的最多的 action 之一了

有了它,编写的 workflow 才有权限去访问我们的仓库。

我们往往使用的时候,就写那么一行

- uses: actions/checkout@v2

这一行的默认配置,使用是获取当前 $GITHUB\_WORKSPACE 下的仓库文件。

显然它的功能不仅如此,它也可以获取任意仓库,只要我们给它提供授权。

访问私有仓库

由图上可知,我们公有仓库里,附加了一个私有仓库作为子模块。

这时候使用 checkout 的默认授权,能够获取私有子模块仓库的代码吗?

显然是不能的,如图所示:

Github Actions: submodule 下公私有仓库授权和通信_第3张图片fatal

所以,我们要给 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 的能力。

Github Actions: submodule 下公私有仓库授权和通信_第4张图片scopes

在获取 token 之后,就可以:

- uses: actions/checkout@v2
  with:
    # Default: ${{ github.token }} ,传参给它更高权限的 token
    token: ${{ secrets.PERSONAL_TOKEN }}
    # 把子模块打开
    submodules: 'true'

于是就能在 public 的action 里轻松的访问 private 的 repo 了。

Github Actions: submodule 下公私有仓库授权和通信_第5张图片success

Workflow dispatch event

下一个问题:

Q: 怎么在私有的B仓库里,触发公有的A仓库的 Action 呢?

A: REST+PAT 授权,远程调用触发

这个大家都非常熟悉了,方法上无非是把 token 作为授权,去调用一个接口,在传参校验成功之后,action 就跑起来了,大家看到的那些 openapi,云厂商的 SDK 都是这么做的。

Github 也是如此, 上图。

声明可触发

首先需要在 workflows 文件里,加一行:

on:
  workflow_dispatch:

代表此 action 可被 workflow event 触发。

接着就可以进行下一步。

RESTful API

Github Actions: submodule 下公私有仓库授权和通信_第6张图片rest api

图上的参数暴露了一切 , 英文已经解释的非常清楚了。

那么我们触发一个任意仓库里的 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 : lernaworkspace ,submodule 等等解决方案很多。

CI/CD 的解决方案也很多,各种写法,各种文档,API 不尽相同。

写前端,客户端,app,解决方案也很多。

我们程序员在学习中,能够体会到本质,举一反三,便是最好的状态。

附录

源码

RESTful API官方链接

你可能感兴趣的:(Github Actions: submodule 下公私有仓库授权和通信)