除了 GitHub 官方托管的 runner 之外，Action 还允许运用线下本人的机器作为 Runner 来跑 Action 的 job。在机器上安装好 Action Runner 之后，按照 教程，将其注册到项目后，在 workflow 文件中经过配置 runs-on: self-hosted 即可运用。

self-hosted 的机器可以打上不同的 label，这样便可以经过 不同的标签 来将义务分发到特定的机器上。比如线下的机器安装有不同的操作系统，那么 job 就可以依据 runs-on 的 label 在特定的机器 上运转。self-hosted 也是一个特定的标签。

安全

GitHub 官方是不引荐开源项目运用 Self-Hosted 的 runner 的，缘由是任何人都可以经过提交 PR 的方式，让 runner 的机器运转风险的代码对其所在的环境停止攻击。

但是 Nebula Graph 的编译需求的存储空间较大，且 GitHub 只能提供 2 核的环境来编译，不得已还是选择了自建 Runner。思索到安全的要素，停止了如下方面的安全加固：

虚拟机部署

一切注册到 GitHub Action 的 runner 都是采用虚拟机部署，跟宿主机做好第一层的隔离，也更方便对每个虚拟机做资源分配。一台高配置的宿主机可以分配多个虚拟机让 runner 来并行地跑一切收到的义务。

假设虚拟机出了成绩，可以方便地停止环境恢复的操作。

网络隔离

将一切 runner 所在的虚拟机隔离在办公网络之外，使其无法直接拜访公司外部资源。即使有人经过 PR 提交了恶意代码，也让其无法拜访公司外部网络，形成进一步的攻击。

Action 选择

尽量选择大厂和官方发布的 action，假设是运用团体开发者的作品，最好能检视一下其详细实现代码，以免出现网上爆出来的 走漏隐私密钥 等事情发作。

比如 GitHub 官方维护的 action 列表：

https://github.com/actions

私钥校验

GitHub Action 会自动校验 PR 中能否运用了一些私钥，除却 GITHUB_TOKEN 之外的其他私钥（经过 $ {{secrets.MY_TOKENS}} 方式援用）均是不可以在 PR 事情触发的相关义务中运用，以防用户经过 PR 的方式私自打印输入窃取密钥。

环境搭建与清算

关于自建的 runner，在不同义务（job）之间做文件共享是方便的，但是最后不要遗忘每次在整个 action 执行完毕后，清算产生的中间文件，不然这些文件有能够会影响接上去的义务执行和不断地占用磁盘空间。

- name: Cleanup 

       if: always() 

       run: rm -rf build 

将 step 的运转条件设置为 always() 确保每次义务都要执行该步骤，即使中途出错。

基于 Docker 的 Matrix 并行构建

由于 Nebula Graph 需求在不同的系统上做编译验证，在构建方式上采用了容器的方案，缘由是构建时不同环境的隔离复杂方便，GitHub Action 可以原生支持基于 docker 的义务。

Action 支持 matrix 策略运转义务的方式，相似于 TravisCI 的 build matrix。经过配置不同系统和编译器的组合，我们可以方便地设置在每个系统下运用 gcc 和 clang 来同时编译 nebula 的源码，如下所示：

jobs: 

  build: 

    name: build 

    runs-on: ubuntu-latest 

    strategy: 

      fail-fast: false 

      matrix: 

        os: 

          - centos6 

          - centos7 

          - ubuntu1604 

          - ubuntu1804 

        compiler: 

          - gcc-9.2 

          - clang-9 

        exclude: 

          - os: centos7 

            compiler: clang-9 

上述的 strategy 会生成 8 个并行的义务（4 os x 2 compiler），每个义务都是（os, compiler）的一个组合。这种相似矩阵的表达方式，可以极大的增加不同纬度上的义务组合的定义。

假设想扫除 matrix 中的某个组合，只需将组合的值配置到 exclude 选项下面即可。假设想在义务中拜访 matrix 中的值，也只需经过相似 $ {{matrix.os}} 获取上下文变量值的方式拿到。这些方式让你定制本人的义务时都变得十分方便。

运转时容器

我们可以为每个义务指定运转时的一个容器环境，这样该义务下的一切步骤（steps）都会在容器的外部环境中执行。相较于在每个步骤中都套用 docker 命令要繁复明了。

container: 

     image: vesoft/nebula-dev:${{ matrix.os }} 

     env: 

       CCACHE_DIR: /tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }} 

对容器的配置，像在 docker compose 中配置 service 一样，可以指定 image/env/ports/volumes/options 等等 参数。在 self-hosted 的 runner 中，可以方便地将宿主机上的目录挂载到容器中做文件的共享。

正是基于 Action 下面的容器特性，才方便的在 docker 内做后续编译的缓存减速。

7. 编译减速 (责任编辑：admin)