6.2 KiB
配置gitea的action用来执行ci操作
虽然gitea的ci写起来真的真的没有gitlab的好写
但是我还是像eat shit 一样找到了一条解决方法
因为gitea社区对其在k8s中的部署文档支持真的很差
总之终于是补齐了自己对于gitea部署的一块重要拼图
运行逻辑
我个人对gitea的action的理解逻辑是这样的
ci配置-->runner-->job
三个基础流程，每一层都有着对应的配置，接下来我将分享我是怎么做的，以及常见的问题
第一步：注册runner到gitea
我使用的是gitea官方1.24.6的chart包安装的
根据我的研究，runner需要自己另外使用deployment或者一个完整的chart，我这里直接使用deployment实现
使用官方的镜像 gitea/act_runner:latest 作为pod运行的基础镜像
此时需要通过deployment的环境变量传递四个关键参数：
GITEA_INSTANCE_URL #gitea的远程地址，就是自己访问的域名；
GITEA_RUNNER_REGISTRATION_TOKEN #gitea注册runner时需要的域名；分为三种等级，项目、组织或个人、全局，分别对应着仓库、组织或个人、管理员的设置的action栏目下的runner中，右上角创建runner即可复制token，gitea会针对token自己创建对应的等级；
GITEA_RUNNER_NAME #runner的名字，就是直接显示在gitea上的名字
CONFIG_FILE #runner的配置文件,用来处理接下来会提到的一个网络配置
我们要修改config_file示例中，container的network字段为host或者其他自己的网络，否则runner创建的container将无法连接到任何服务
使用configmap预先包装到同一命名空间做好准备，例如这样：
(labels建议换成相对规范的格式,可以有多个)
apiVersion: v1
kind: ConfigMap
metadata:
name: gitea-act-runner-config
namespace: gitea-actions
data:
config.yaml: |
log:
level: info
runner:
name: rke2-runner-1
labels:
- "gitea-official-runner:docker"
capacity: 2
timeout: 1h
container:
network: host
cache:
enabled: true
dir: /data/cache
然后编写deployment，像这样：
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitea-runner
namespace: gitea-actions
spec:
replicas: 1
selector:
matchLabels:
app: gitea-runner
template:
metadata:
labels:
app: gitea-runner
spec:
containers:
- name: runner
securityContext:
privileged: true
image: gitea/act_runner:latest
args:
- "daemon"
env:
- name: CONFIG_FILE
value: /data/config.yaml
- name: GITEA_INSTANCE_URL
value: "https://gitea.example.com"
- name: GITEA_RUNNER_REGISTRATION_TOKEN
value: ""
- name: GITEA_RUNNER_NAME
value: "runner"
volumeMounts:
- name: runner-data
mountPath: /data
- name: runner-config
mountPath: /data/config.yaml
subPath: config.yaml
- mountPath: /var/run/docker.sock
name: docker-socket
- mountPath: /root/.docker/config.json
name: docker-token
volumes:
- name: runner-data
emptyDir: {}
- name: runner-config
configMap:
name: gitea-act-runner-config
- name: docker-socket
hostPath:
path: /var/run/docker.sock
- name: docker-token
hostPath:
path: /root/.docker/config.json
解释一下为什么要挂在docker-socket和docker-token
主要是为了使用拉取镜像的功能，这里不得不提一下action是怎么运行的了
运行逻辑
runner使用的镜像只是一个守护进程，可以理解为用来和gitea保持联系的进程，后面使用的镜像才是重头戏，所以，runner就必须要使用到docker的套接字去使用docker pull命令
因为官方act_runner镜像自己没有带docker，所以我这里使用的是宿主机的docker.sock；当然，你也可以指定一个DinD的镜像，比如把act_runner替换成vegardit/gitea-act-runner:dind-latest
注意：如果你的集群有严格的安全限制，那么应该只能使用DinD镜像，因为官方镜像需要访问宿主机的sock，需要privileged权限
如果要从私有仓库拉取镜像，就还需要加上config.json，里面保存着登录凭证可以直接供拉取镜像时使用，我这边因为用的就是宿主机的docker，所以顺便也用宿主机的认证了
至此，runner注册完成，应该可以在管理面板查看存在的runner
第二步：编写workflow
先上代码：
name: Docker Image CI
on:
push:
branches:
- main
jobs:
build:
runs-on: gitea-official-runner
container:
image: harbor.merlin.xin/testing/merlin/builder:v0.0.0
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: see ls
run: ls
关键
on：触发条件，push、pull等，再加上branches，就像例子中的层级关系一样
jobs：任务列表，可以写多个，会根据第一步中的配置判断是否并行
重点是jobs里面操作的container，多数情况下，我们会使用第三方镜像去构建docker镜像，但是要注意可能需要node环境执行脚本
如果你的steps里面包含了github action的官方脚本比如actions/checkout@v4，那么就要求container镜像里面得包含node环境
gitea不像gitlab，gitea action不会自动把代码拉取到运行环境，所以目前actions/checkout@v4这个脚本基本上必须要有
你自己运行git clone也行，但是要自己处理私有仓库的认证问题，很麻烦；脚本会自己生成临时token，与gitea配合拉取代码
所以后面你想用三方镜像，要么镜像自带node，要么自己打包一个node进去
第三步：触发action
通过推送代码触发ci，观察一下日志的输出结果
有报错的话做一下细微的调整就好
注意事项/容易踩坑
构建容器的容器网络联通性
如果出现steps里面的操作无法上网,那就是coontainer.network没配置好，这个要自己预先设置好