Gitea Actions 实战指南5 步跑通你的第一条自动化测试流水线【免费下载链接】giteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD项目地址: https://gitcode.com/GitHub_Trending/gi/gitea上次上线又翻车了本地测试全绿到了生产环境一个边界场景没覆盖晚上十点你被迫爬起来热修。如果代码合入前就有一道自动测试的闸门这个事故大概率不会发生。而搭这道闸门不需要再引入一整套外部 CI 平台——Gitea Actions 是 Gitea 内置的轻量级 CI/CD 能力支持自动化测试、构建和部署而且和 GitHub Actions 的写法高度兼容会那边的基本无脑平移。下面我们就拿一个再普通不过的例子做主线一个 Go 后端项目仓库里就main.go、go.mod和几个测试文件。5 步之内让你的一条流水线真正跑起来。第 1 步先跑通——你的第一条流水线别急着学概念概念我们待会儿拆。现在只做一件事让推送代码 → 自动跑测试发生。在仓库根目录新建一个文件.gitea/workflows/ci.yml内容如下这是最小可用版本别删name: Go Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - name: 拉取代码 run: git fetch --depth 1 origin $GITEA_SHA git checkout FETCH_HEAD - name: 跑测试 run: go test ./...保存推上去。仓库页顶部的标签栏会出现一个Actions入口点进去你会看到一条正在转的任务。几十秒后它变成绿色对勾——恭喜流水线跑通了。如果你不想手写 YAML也可以直接用仓库页的Actions → 编辑默认 workflow界面里改完点保存文件会自动提交到上面那个路径。跑通之后回头看这个文件其实只回答了两个问题什么时候触发on里的 push 和 pull_request以及触发后干什么jobs.test.steps里的命令。剩下所有花活都是在这两个问题的基础上加料。把积木拆开看Workflow、Job、Step、Runner流水线跑通后建议把脑子里的模型从配置文件换成工厂车间后面的一切特性都能挂进去Workflow 排班表。一份 YAML写清楚遇到什么事、安排哪些工位、按什么顺序干活。Job 工位。每个 Job 有独立的运行环境、独立的失败判定。排班表上可以排多个工位它们默认并行开工。Step 工位上的操作说明。一行命令、一次取件、一次上传都是 Step。Step 按顺序执行某一步失败这个工位就停工。Runner 工人。真正搬砖的是它——一台跑在你服务器或容器、K8s上的常驻进程从 Gitea 领任务、执行、回传日志和状态。runs-on: ubuntu-latest里的字符串本质上是给工人贴的工牌标签你的 Runner 没贴这个标签任务就会一直排队没人接。四者的关系一条线就能画完想深入看这些积木在代码里怎么实现的可以从 models/actions/Run、Job、Runner、Artifact 等数据模型和 services/actions/任务分发与执行服务这两个目录入手读源码是理解行为边界最快的方式。第 2 步把地基打好——启用 Actions 并注册 Runner第一次跑之前其实有两个开关。如果你的仓库还没配置好任务会一直停在等待 Runner那就是这两个开关没打开。一键启用 Actions 功能两种任选其一界面管理员登录 → 站点管理 → 配置 → Actions → 打开启用 Actions保存。配置文件在app.ini里确认这两行示例模板见 custom/conf/app.example.ini[ACTIONS] ENABLED true仓库层面还要再开一个开关进入仓库 → 设置 → 功能 → 勾选 Actions。最快注册 Runner 的方法Runner 是一个独立的轻量二进制act_runner三步搞定# 1. 在 Gitea 的 Actions 管理页创建 Runner页面会给你注册命令和 token # 2. 在目标机器上拉取二进制并注册--labels 要和 runs-on 对齐 ./act_runner register --no-interactive \ --instance https://your-gitea.com \ --token 注册token \ --name my-runner \ --labels ubuntu-latest # 3. 作为常驻服务跑起来 ./act_runner daemon两个细节容易踩坑--labels必须和 workflow 里runs-on的标签一字不差多一个空格都不行。act_runner daemon建议丢进 systemd 或 supervisor 托管否则机器重启后流水线直接瘫痪。更省事的路径也有如果整套 Gitea 就跑在 Kubernetes 上可以直接用gitea actions-runner这种容器化 RunnerK8s 会替你管进程生命周期。第 3 步进阶玩法——依赖、矩阵与密钥地基打牢之后流水线该长出牙齿了。还是那个 Go 项目我们让它更像一个真实的发布流程。多阶段依赖测试不过就不许构建想让构建必须等测试通过用needs声明工位之间的先后关系jobs: test: runs-on: ubuntu-latest steps: - run: git fetch --depth 1 origin $GITEA_SHA git checkout FETCH_HEAD - run: go test ./... build: needs: test # test 挂了build 直接跳过 runs-on: ubuntu-latest steps: - run: git fetch --depth 1 origin $GITEA_SHA git checkout FETCH_HEAD - run: go build -o bin/app . zip app.zip bin/app不写needs的 Job 默认并行所以测试、lint、构建三个没有依赖关系的 Job 会同时开工互不阻塞。矩阵测试一套配置多版本全测要同时验证 Go 1.21 和 1.22不用复制两份 Jobtest: runs-on: ubuntu-latest strategy: matrix: go: [1.21, 1.22] fail-fast: false # 一个版本挂了别把其他组合也掐了 steps: - run: ... # 用 ${{ matrix.go }} 切换版本strategy.matrix会把 Job 按维度自动展开成多个实例fail-fast: false保证某个组合失败时其余组合照常跑完——你一次就能看到全部坏点。环境变量与密钥密码永远不进仓库部署要用的 token、密码放在仓库设置 → Actions Secrets或组织级 Secrets里workflow 中用${{ secrets.XXX }}引用日志里自动打码- name: 部署 env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }} run: ./deploy.sh --token $DEPLOY_TOKEN配合environment: production还能给部署阶段加人工审批卡点——生产环境的闸门值得多一道人工确认。第 4 步打通外部世界——镜像构建与代码质量流水线不只是一条测试线它还是你对接外部服务的统一出口。构建并推送 Docker 镜像Go 项目发布静态二进制是家常便饭把构建产物打成镜像推出去- name: 构建并推送镜像 run: | docker build -t registry.example.com/myapp:${GITEA_SHA} . docker push registry.example.com/myapp:${GITEA_SHA}用$GITEA_SHA打 tag每个提交对应一个可追溯的镜像版本再叠加tags: [v*]的触发条件打 tag 时自动多推一个latest。接入代码质量工具覆盖率、静态检查这类第三方服务本质上都只是在 Runner 上多跑几条命令 传个 token- name: 覆盖率 run: go test -coverprofilecoverage.out ./... cat coverage.out有了coverage.out接不上云服务的就本地解析接得上的就按对应服务客户端的文档补一步上传即可——Gitea Actions 对 GitHub Actions 生态的兼容性意味着大量现成 Action 可以直接参考着搬。第 5 步提速与排障——高频踩坑清单流水线用起来之后速度和问题是永恒话题。把大家最常问的合并成一张清单提速三板斧缓存go build的缓存目录和模块目录加进缓存步骤key 用go.sum的内容哈希依赖没变就不重新下载二次构建通常快一半以上。并行把没依赖关系的 Job 拆开并行测试 / lint / 安全扫描总时长由最慢的一条决定。浅克隆测试场景用--depth 1别把整个 Git 历史搬上 Runner。高频踩坑清单症状大概率原因任务一直等待 Runner不启动Runner 没在跑、或runs-on标签与注册时的--labels对不上推了代码没触发workflow 文件不在.gitea/workflows/下、扩展名不是.yml/.yaml、或仓库设置里 Actions 没开缓存不生效key 设计没覆盖依赖变化、缓存路径写错、Runner 对缓存目录无写权限本地能跑、流水线挂依赖版本没锁定、Go 版本不一致——用矩阵测试固化环境组合部署失败说不清日志没分层给每个 Step 起个名字失败时先定位到 Step 再看日志你能带走什么到这里5 步走完了回头盘点一下你手里有了什么一条会跑测试的最小流水线——.gitea/workflows/ci.yml推送即触发一个清晰的脑子里的模型——排班表Workflow、工位Job、操作Step、工人Runner两个开关——站点级启用 仓库级开启 Runner 标签对齐一套进阶套路——needs串依赖、matrix展开环境、secrets管敏感值一张排障清单——下次任务卡住照表排查十分钟定位。下一步建议直接动手翻一翻 models/actions/ 和 services/actions/ 里的模型与服务代码把任务是怎么被分发、重试、回收的看透再把部署阶段接上你的真实服务器让合入即上线成为默认流程。现在就去给你的仓库建.gitea/workflows目录写下第一条流水线吧——今晚的线上事故可以就此画上句号。【免费下载链接】giteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD项目地址: https://gitcode.com/GitHub_Trending/gi/gitea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考