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