Gitea Actions 完整指南：30 分钟搭好你的 CI 流水线

Gitea Actions 完整指南30 分钟搭好你的 CI 流水线【免费下载链接】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凌晨两点监控告警把手机震醒线上直接 502。白天你手动跑过构建和测试可发布时是一条条命令敲下来的其中一步漏了测试步骤压根没在这个环境里跑过全靠记忆执行。问题出在哪没有机器替你兜底构建、测试、发布这几步。Gitea Actions 干的就是这件事把这些手动步骤变成持续集成流水线每次提交自动触发自动化构建结果直接告诉你。快速认知Actions 到底是什么Gitea Actions 就是 Gitea 内置的 CI/CD 系统你在仓库里放一个 YAML 文件代码一推送它就开始自动构建、自动测试。整条链路不长核心概念只有三个先混个脸熟Workflow一条完整的自动化流程存在仓库.gitea/workflows/目录下的.yml文件里。JobWorkflow 里的独立执行单元每个 Job 单独分配一个执行环境。StepJob 里的最小动作要么跑一条命令要么引用一个现成的 Action。这三个词搞懂了任何流水线配置你都能看懂个大概。从零搭建你的第一条流水线第一步启用 Actions 并注册 Runner流水线要动得先有台机器接单。先去管理后台的站点管理 → 配置 → Actions 页勾选启用 Actions再进目标仓库的设置确认 Actions 功能对仓库开放。然后到仓库的 Actions 页面点新建 Runner复制生成的 token在一台 Linux 机器上安装。下面这两条命令下载并解压 Runner 二进制官方为各平台提供编译好的包wget https://dl.gitea.com/act_runner/0.2.10/act_runner-0.2.10-linux-amd64.tar.gz tar xzf act_runner-0.2.10-linux-amd64.tar.gz版本号替换成发布页最新的那版就行Runner 协议迭代快别用太老的版本。接着用刚才复制的 token 注册这台 Runner./act_runner register --no-interactive \ --config /etc/act_runner/config.toml \ --instance https://git.example.com \ --token 你复制的token \ --name ci-runner-01 \ --labels linux,amd64--labels决定了这台机器能接什么活后面 YAML 里的runs-on必须和它对得上对不上任务就永远排队。注册成功后启动常驻进程./act_runner daemon生产环境建议把它挂进 systemd否则终端一关Runner 也跟着没了。Runner 就位下一步就是给它写工作说明书。第二步编写你的第一个 Workflow 文件在仓库的.gitea/workflows/目录下新建ci.yml内容直接照抄name: ci # 只在 main 分支的 push 和 PR 时触发省得每个分支都跑 on: push: branches: [main] pull_request: branches: [main] jobs: check: # 标签必须和 Runner 注册的 labels 完全一致 runs-on: [linux, amd64] steps: - name: 拉取代码 uses: actions/checkoutv4 - name: 安装 Go # 版本钉死别让碰巧有什么决定构建结果 uses: actions/setup-gov5 with: go-version: 1.26 - name: 构建 run: go build ./... - name: 单元测试 # -count1 关掉测试缓存保证每次都是真跑 run: go test -count1 ./...配置放在仓库里还有个好处它跟代码一样走版本管理和 PR 评审谁改了流水线一目了然。文件写好了但每行到底在干嘛逐字段过一遍。逐字段解读on / jobs / steps / needs / runs-onon是触发开关定义什么时候跑比如 push、PR、定时任务。jobs是任务集合每个任务有独立环境天然可以并行。steps是任务内的动作清单从上到下顺序执行。runs-on挑选 Runner标签必须和注册时一字不差。needs声明依赖依赖的任务全过了它才开跑。⚠️runs-on的标签是最常见的隐形杀手错一个字母任务就永久排队而且日志里不会直接报错给你看。配置读懂了推上去之后还得会看结果。第三步查看执行结果、定位失败步骤代码推上去后仓库的 Actions 页面会多出一条运行记录绿勾通过红叉失败。点进运行详情每个 Job、每个 Step 的日志独立成块失败的 Step 会被标出来直接定位到报错那一行不用在一万多行日志里翻。提交页面也会挂一个状态标记review PR 的人不用切去 Actions 页面就知道测试过没过。进阶玩法让流水线更聪明用 needs 串起三步流水线一个 Job 从头干到尾构建十分钟你受得了吗把测试、构建、部署拆成三个 Job用needs串起来测试不过就根本不进构建环节省时间也省资源jobs: test: runs-on: [linux, amd64] steps: - uses: actions/checkoutv4 - run: go test ./... build: needs: [test] # 测试通过才允许构建 runs-on: [linux, amd64] steps: - run: go build -o dist/app ./... deploy: needs: [build] # 三步串联的最后一环 runs-on: [linux, amd64] steps: - run: echo deploying dist/app关键价值是短路一行代码改挂了测试流水线在测试阶段就停下不会带着坏包往下走。一次提交跑六个环境在我机器上是好的十有八九是环境差异。把版本和系统的组合写进 matrixGitea 会自动为每种组合起一个 Job 并行跑兼容性问题在合并前就全暴露出来jobs: test: runs-on: [linux, amd64] strategy: # 2 个 Go 版本 × 3 个系统共 6 组并行 matrix: go-version: [1.25, 1.26] os: [linux, windows, macos] steps: - uses: actions/checkoutv4 - uses: actions/setup-gov5 with: go-version: ${{ matrix.go-version }} - run: go test ./...前提是三种系统的 Runner 都得注册上缺哪个组合哪个就排队。踩坑与排错1. Workflow 不触发现象推完代码Actions 页面一条运行记录都没有。 原因文件不在.gitea/workflows/下目录名和大小写都要对或者仓库设置里没开 Actions。 解决先查路径再查开关九成是这俩之一。2. 依赖缓存失效现象每次构建都重新拉全量依赖一次十分钟。 原因缓存键没包含go.sum依赖变了缓存却不会跟着失效或者键每次都变永远命中不了。 解决键用hashFiles(**/go.sum)拼依赖一变自动换键。3. Runner 连接超时现象任务一直挂着Runner 日志安静得像没发生过什么。 原因Runner 连不上 Gitea——防火墙拦了或者--instance填了 Runner 访问不到的内网地址。 解决在 Runner 机器上curl一下实例地址通了再查网络策略。收尾一句话Runner 是干活的机器YAML 是工作说明书needs和 matrix 让流水线跑得又省又全。下一步就一件事——把文中的ci.yml改成你项目自己的构建命令推上去看一次绿勾。遇到什么坑评论区见有补充的欢迎拍砖。【免费下载链接】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），仅供参考