Nebula Graph 的源码采用 C++ 编写，整个构建进程时间较长，假设每次 CI 都完全地重新末尾，会糜费许多计算资源。由于每台 runner 跑的（容器）义务不定，需求对每个源文件及对应的编译进程停止精准判别才能确认该源文件能否真的被修正。目前运用最新版本的 ccache 来完成缓存的义务。
虽然 GitHub Action 本身提供 cache 的功用，由于 Nebula Graph 目前单元测试的用例采用静态链接，编译后体积较大，超出其可用的配额，遂运用本地缓存的策略。
ccache
ccache 是个编译器的缓存工具，可以有效地减速编译的进程，同时支持 gcc/clang 等编译器。Nebula Graph 运用 C++ 14 标准，低版本的 ccache 在兼容性上有成绩，所以在一切的 vesoft/nebula-dev 镜像 中都采用手动编译的方式安装。
Nebula Graph 在 cmake 的配置中自动辨认能否安装了 ccache，并决议能否对其翻开启用。所以只需在容器环境中对 ccache 做些配置即可，比如在 ccache.conf 中配置其最大缓存容量为 1 G，超出后自动交流较旧缓存。
max_size = 1.0G
ccache.conf 配置文件最好放置在缓存目录下，这样 ccache 可方便读取其中内容。
tmpfs
tmpfs 是位于内存或许 swap 分区的暂时文件系统，可以有效地缓解磁盘 IO 带来的延迟，由于 self-hosted 的主机内存足够，所以将 ccache 的目录挂载类型改为 tmpfs，来增加 ccache 读写时间。在 docker 中运用 tmpfs 的挂载类型可以参考 相应文档。相应的配置参数如下：
env:
CCACHE_DIR: /tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}
options: --mount type=tmpfs,destination=/tmp/ccache,tmpfs-size=1073741824 -v /tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}:/tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}
将一切 ccache 产生的缓存文件，放置到挂载为 tmpfs 类型的目录下。
并行编译
make 本身即支持多个源文件的并行编译，在编译时配置 -j $(nproc) 便可同时启动与核数相反的义务数。在 action 的 steps 中配置如下：
- name: Make
run: cmake --build build/ -j $(nproc)
8. 坑说了那么多的优点，那有没有不足呢？运用上去主要体会到如下几点：
只支持较新版本的系统。很多 Action 是基于较新的 Nodejs 版本开发，没法方便地在相似 CentOS 6 等老版本 docker 容器中直接运用。否则会报 Nodejs 依赖的库文件找不到，从而无法正常启动 action 的执行。由于 Nebula Graph 希望可以支持 CentOS 6，所以在该系统下的义务不得不需求特殊处置。
不能方便地停止本地验证。虽然社区有个开源项目 act，但运用上去还是有诸多限制，有时不得不经过在本人仓库中重复提交验证才能确保 action 的修正正确。
目前还缺少比较好的指点标准，当定制的义务较多时，总有种在 YAML 配置中写顺序的感受。目前的做法主要有以下三种：
依据义务拆分配置文件。
定制专属 action，经过 GitHub 的 SDK 来完成想要的功用。
编写大的 shell 脚本来完成义务内容，在义务中调用该脚本。
目前针对尽量多运用小义务的组合还是运用大义务的方式，社区也没有定论。不过小义务组合的方式可以方便地定位义务失败位置以及确定每步的执行时间。
Action 的一些历史记载目前无法清算，假设中途更改了 workflows 的名字，那么老的 check runs 记载还是会不断保留在 Action 页面，影响运用体验。
目前还缺少像 GitLab CI 中手动触发 job/task 运转的功用。无法运转中间停止人工干预。
action 的开发也在不停的迭代中，有时需求维护一下新版的晋级，比如：checkout@v2
不过总体来说，GitHub Action 是一个相对优秀的 CI/CD 系统，毕竟站在 GitLab CI/Travis CI 等先人肩膀上的产品，还是有很多阅历可以自创运用。
9. 后续定制 Action
前段时间 docker 发布了本人的第一款 Action，简化用户与 docker 相关的义务。后续，针对 Nebula Graph 的一些 CI/CD 的复杂需求，我们亦会定制一些专属的 action 来给 nebula 的一切 repo 运用。通用的就会创立独立的 repo，发布到 action 市场里，比如追加 assets 到 release 功用。专属的就可以放置 repo 的 .github/actions 目录下。
这样就可以简化 workflows 中的 YAML 配置，只需 use 某个定制 action 即可。灵敏性和拓展性都更优。
跟钉钉 /slack 等 IM 集成
(责任编辑：admin)