203 lines
6.2 KiB
Markdown
203 lines
6.2 KiB
Markdown
# 配置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示例](./attachments/gitea_act-runner_config-template.yaml)中，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没配置好，这个要自己预先设置好
|
||
|
||
|