feat: add gitea runner relavant ex.

配置gitea的action用来执行ci操作.md

@@ -0,0 +1,149 @@
+# 配置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