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没配置好,这个要自己预先设置好