基于Gitea Actions Runner搭建代码提交自动测试流水线
代码变更后自动触发测试，能够第一时间捕获改动引入的缺陷。本文在原有 team-notes 仓库基础上，部署专属的 Gitea Actions Runner；先提交一条存在断言错误的测试用例，再修复用例重新推送，对比观察 Gitea 工作流页面的失败日志与成功执行结果。
1. 确认仓库工作流已启用
本次使用 Gitea 28.2.0，部署在 Compose 环境且已开启 Actions 能力。先通过 API 将仓库 has_actions 设置为 true，随后进入仓库【设置 → 工作流 → 常规】页面，确认 “启用仓库工作流” 选项已勾选。
本次复用原有仓库与主分支，不额外搭建独立代码服务。
2. 准备 Runner 和任务镜像
参照官方文档选用 Gitea Runner 5.2.0，采用基础镜像搭配宿主机 Docker 的方案。本次测试单独新建测试仓库，任务流程仅包含检出代码、执行 Node 测试两步。
docker pull docker.io/gitea/runner:5.2.0
docker pull docker.io/library/node:22-bookworm
镜像拉取完成。任务镜像内置 Node v22.23.4、Git 2.39.5，无需在每次测试执行时重复安装工具。
3. 连通实例地址与容器网络
浏览器通过 SSH 隧道访问 Gitea，但 Runner 不使用本机 127.0.0.1 地址。Runner 加入 Gitea 所在的 Compose 自定义网络，注册访问地址填写 http://server:3000；测试任务容器同样接入该网络。 在 Node 容器内访问 http://server:3000/api/v1/version，返回版本号 28.2.0，验证 Runner 以及后续任务容器均可正常访问 Gitea 服务。
runner-config.yaml 仅保留本次演练所需配置：
runner:
capacity: 1
container:
network: docx202610-gitea_default
force_pull: false
docker_host: "-"
force_pull: false 表示优先使用本地已拉取的任务镜像；Runner 挂载宿主机 Docker Socket，docker_host: "-" 避免将 Socket 继续透传给测试任务容器。
4. 注册仓库专用 Runner
使用仓库级注册令牌，让该 Runner 仅为 lin/team-notes 仓库提供服务。注册令牌存入权限为 600 的临时文件，通过挂载文件方式读取，不直接写在 Compose 配置中。
services:
runner:
image: docker.io/gitea/runner:5.2.0
container_name: docx202610-gitea-runner
restart: unless-stopped
environment:
GITEA_INSTANCE_URL: http://server:3000
GITEA_RUNNER_NAME: docx-node22
GITEA_RUNNER_LABELS: docx-node22:docker://node:22-bookworm
GITEA_RUNNER_REGISTRATION_TOKEN_FILE: /registration-token
CONFIG_FILE: /runner-config.yaml
volumes:
- ./runner-data:/data
- ./runner-config.yaml:/runner-config.yaml:ro
- ./runner-registration-token:/registration-token:ro
- /var/run/docker.sock:/var/run/docker.sock
将上述配置保存为同目录下 runner.yaml，和原有 Gitea 配置组合启动：
cd /opt/docx-202610/gitea
docker compose -f compose.yaml -f runner.yaml up -d runner
docker compose -f compose.yaml -f runner.yaml ps runner
进入仓库【设置 → 工作流 → 运行器】页面，列表中可看到 docx-node22，版本 v5.2.0，作用域为仓库级，标签匹配 docx-node22。截图时 Runner 状态为在线空闲。
5. 编写最小工作流
在本地项目新建 .gitea/workflows/node-tests.yaml，任务标签和 Runner 标签保持一致；执行步骤依次为检出代码、打印 Node 版本、运行 npm 测试。
name: Node.js tests
on: [push]
jobs:
test:
runs-on: docx-node22
steps:
- name: Check out repository
uses: builtin:checkout
- name: Show runtime
run: node --version
- name: Run tests
run: npm test
这里使用 Runner 5.x 系列原生支持的 builtin:checkout，无需额外拉取第三方检出 Action。package.json 内的测试命令沿用之前预置的 node --test。
6. 推送预期失败的测试用例
新增 totals.test.js，使用 Node 内置测试模块。为复现断言失败场景，故意将加法测试的预期结果写为 6；另一条用例校验金额格式化输出是否带有 “元” 字。
const test = require("node:test");
const assert = require("node:assert/strict");
const { add, formatTotal } = require("./totals");
test("adds two numbers", () => {
assert.equal(add(2, 3), 6);
});
test("formats a total with currency", () => {
assert.equal(formatTotal(5), "合计：5 元");
});
在主分支提交并推送新增文件：
git add .gitea/workflows/node-tests.yaml totals.test.js
git commit -m "Add failing test to exercise Actions"
git push origin main
提交 5f39763 触发工作流 #1，任务最终状态为失败。
7. 在日志定位失败原因
打开本次任务详情，展开【Run tests】步骤。检出代码、打印运行环境两步均执行成功；测试日志明确输出 expected: 6、actual: 5，并定位到 totals.test.js。
本次失败是人为设置的断言错误，不属于 Runner 注册、代码拉取、环境依赖层面的故障，无需重建容器。
8. 修正预期值，再次推送验证
修改加法测试断言：
assert.equal(add(2, 3), 5);
其余代码、工作流配置保持不变，再次提交推送：
git add .gitea/workflows/node-tests.yaml totals.test.js
git commit -m "Fix addition test expected value"
git push origin main
提交 189ed7e 触发新一轮工作流 #2，页面状态显示成功，三个执行步骤全部通过。
展开成功任务的测试日志，两条用例均标记 ok，统计结果：pass 2、fail 0。
两次运行记录分别绑定对应提交，日志独立保存。后续只要修改项目代码并推送，即可复用这套工作流查看测试结果。本次仅实现自动测试，未新增发布、部署相关步骤。 演练取证完成后，测试机上的专属 Runner 停止运行，同时清除注册记录；仓库本身以及两次工作流运行记录保留。后续如需再次演练，重新注册 Runner 即可。
广告合作
QQ群号：4114653
- 本网站发布的内容(图片、视频和文字)以原创、转载和分享网络内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。邮箱：2942802716#qq.com（#改为@）。
- 本站原创内容未经允许不得转载，转载请注明出处“站长百科”和原文地址。
