持续集成-gitea-runner

此文目前是草稿状态

简述

优点:

一套系统完成开发过程中的主要功能, 不需要在多个系统之间切换
基本兼容 github actions, 生态友好
支持docker和NodeJs 类型的 actions 插件, 上手很容易
基本是中小型私有化场景部署的首选了

缺点:

太新, 今年初才发布；
更新慢, 感觉开发团队进展得很慢，团队资源不足的样子；
因为是兼容 github，所以使用过程中需要注意很多地方默认都是 github, 需要手动指定。
最大的缺点: k8s 不友好, 目前只支持 docker

文档(只能看github的):
https://docs.github.com/zh/actions/guides

简述原理

runner 启动后注册到 gitea 等待 webhook
触发事件后拉取代码进行打包发布等操作

要点

runner 的设计拆分为了几个单元

runner 自身

只负责和 gitea 通信和 actions 的调度
可以是二进制启动, 也可以是 docker 容器启动 runner

基础的运行环境

因为大部分或者说是官方主要 actions 的插件都是 nodeJs 开发的,
所以需要一个 nodejs 的运行环境，这个和 runner 是独立开的;

runner 只负责以容器的方式启动一个 nodejs 环境, 然后所有的 js 类型的插件都在这个环境里面运行

如果插件类型是 docker, 则这个 docker action 是在 nodejs 环境运行的;

有几种层级关系

runner
runner – nodejsEnv(docker) – js actions
runner – nodejsEnv(docker) – docker actions(docker)
runner(docker) – nodejsEnv(docker) – docker actions(docker)

涉及到docker镜像

gitea/act_runner:0.2.5
也就是一个docker 的 runner 运行器, 内部除了附加一个 git 外没有别的工具

node:16-bullseye
一个默认的 nodejs 的运行环境, 内部有一些少量的工具支持
如 node npm python gcc 等, 但主要是为了运行 js 类型的 actions
也支持 docker 命令, 目的是运行 docker 类型的 actions

ghcr.io/catthehacker/ubuntu:act-22.04
一个第三方的 actions 运行环境, 参考 github 的
优点是命令和工具带得非常多, 很多时候不需要外部 action 而直接使用 run 执行 shell 命令就可以了

关于自定义action

使用CICD绕不过去的内容就是自定义插件;

github 支持2种插件形式

js 类型的插件, 由运行环境上的 nodejs 直接运行
docker 类型的插件, 由运行环境上的 docker 命令运行，会创建一个新的容器

个人对 js 不大熟悉, 所以还是推荐 docker actions

这里的要点

1
2
3
4
5


- name: actions 的使用格式
    uses: actions/xxxx1:v1
    uses: actions/xxxx1@master
    uses: https://xxxxx/actions/xxxx1@master
    uses: docker://registry.services.wait/cwx/xxxx1:v1

uses 默认会去 github 上拉取仓库代码, 然后根据里面的 action.yml 文件判断这是一个 js 还是 docker 类型的插件。

如果是 js 类型的, 一般就需要执行 npm 先编译插件自身, 然后再执行插件;
如果是 docker 类型的, 就会按照提供的 Dockerfile 来创建一个新的 docker 镜像, 并且执行这个镜像;
因为编译镜像是有缓存的, 所以后续再使用到这个docker镜像, 是不需要重新打包镜像的;

如果是不想去仓库拉取插件的代码, 而是使用已有镜像可以采用这种格式;
uses: docker://registry.services.wait/cwx/xxxx1:v1

镜像插件的参数传递

当需要在 yml 文件内把一个参数传递到运行的 action 镜像内时, 可以如下

1
2
3
4
5


- name: actions 的使用格式
  uses: actions/xxxx1:v1
  with:
    cmd1: zzzz1
    cmd2: zzzz2

with 下面的 key, 会被以环境变量的方式传递到镜像内;
镜像内直接获取对应的环境变量即可获取到值, 但是需要加 INPUT 前缀，如

cmd1=${INPUT_CMD1}
cmd2=${INPUT_CMD2}

输出也是相同道理, 只不过需要定义 OUTPUT 来使用

状态截图

workflows

编译成功