3 步搞定 Gitea Actions提交代码后自动跑测试、构建、部署【免费下载链接】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周五晚上 6 点你手动跑完测试准备上线结果漏跑了接口集成测试发布两小时后线上直接报错。你只能连夜回滚、补跑测试、重新部署整个周末搭了进去。把这件事交给 Gitea Actions 就不一样了提交代码后自动跑一遍测试、构建、部署漏一步都难。它是 Gitea 内置的持续集成CI/CD能力——Gitea 持续集成不用额外装一台 CI 服务器你只需要在仓库里放一个 YAML 文件就能搭起自己的自动化流水线。⚡ 30 秒跑通一键跑通第一个自动化测试结论先行一个 YAML 文件 一台注册好的 Runner你就能看见提交后自动跑测试。第一步在仓库里新建.gitea/workflows/quick-test.yml内容如下不到 15 行name: Quick Test on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-gov5 with: go-version: 1.22 - run: go test ./...第二步注册一台 Runner真正干活的执行机器。进仓库的 Actions 页面点管理 Runner复制页面上给出的 register 命令在你自己的 Linux 机器上执行填上 token 和标签比如ubuntu-latest即可。第三步push 一个提交刷新 Actions 页面。运行结果长这样Run Quick Test ✔ Checkout code (2s) ✔ Set up Go 1.22 (3s) ✔ go test ./... (41s) 1 job passed (46s)绿勾出现的那一刻提交即测试就成立了。 一张图看懂 Workflow、Job、Step、Runner用大白话说Workflow 是你写的那个 YAML 文件Job 是文件里一个个互相独立的任务Step 是 Job 里按顺序执行的一条条指令Runner 则是 Gitea 把 Job 派给谁去跑——你注册机器时打上的标签要和 Job 里runs-on写的一致任务才会被领走。三档能力升级从自动测试到生产部署入门档配置最小工作流让每次提交自动跑测试看懂三个字段你就能读懂任何一个 Gitea 工作流字段干什么用常见取值on触发条件什么时候自动跑push、pull_request、workflow_dispatch手动、schedule定时jobs.xxx.runs-on任务派给哪台 Runner 执行ubuntu-latest等标签需与注册标签一致steps按顺序执行的步骤uses:引用现成 Action如 checkoutrun:直接执行命令想限定只在 main 分支触发就把on展开成push: branches: [main]。就这么多入门档齐了。进阶档多阶段流水线这样搭needs 矩阵 密钥三个能力解决三类问题多阶段排序、多环境覆盖、敏感信息保护。needs定义 Job 之间的先后顺序只有前置任务全绿后续任务才开始jobs: build: needs: test runs-on: ubuntu-latest environment: production steps: - uses: actions/checkoutv4 - name: Build env: APP_TOKEN: ${{ secrets.APP_TOKEN }} VERSION: ${{ github.sha }} run: make build VERSION$VERSIONsecrets.APP_TOKEN对应的值在仓库设置 → Secrets里维护不会出现在代码和日志里environment还能给不同环境如 production挂审批或变量。想一次覆盖多个系统和 Go 版本用strategy.matrix展开笛卡尔积组合strategy: matrix: go-version: [1.21, 1.22] os: [ubuntu-latest, windows-latest]上面两行就是 2×24 个并行任务。配合if: matrix.xxx yyy还能只在特定组合里跑额外检查比如 lint。生产档接入真实部署镜像推送、质量扫描、通知流水线最后一段路是把它接进真实的生产动作。构建并推送容器镜像在 Runner 上装好 docker 后两步搞定- uses: docker/login-actionv3 with: username: ${{ secrets.REGISTRY_USER }} password: ${{ secrets.REGISTRY_PASS }} - uses: docker/build-push-actionv6 with: context: . push: true tags: ${{ github.repository }}:${{ github.sha }}质量扫描在 test 阶段追加覆盖率产出go test -coverprofilecoverage.out和静态检查步骤把报告作为构建产物上传actions/upload-artifact失败时日志直接留在 Actions 页面。通知在 Job 末尾加一个if: failure()的 step用curl把失败信息 POST 到你的 IM webhook成功则保持安静避免刷屏。到这一步你的 Gitea 构建部署流水线已经完整push 触发 → 测试 → 构建 → 推镜像 → 通知全程无人值守。避坑清单三类高频问题的现象、原因、解法现象常见原因解法Workflow 一直不触发① 文件不在.gitea/workflows/或扩展名不是.yml②on没覆盖当前分支③runs-on标签没有任何 Runner 匹配任务会永远排队核对路径与扩展名把事件范围扩到对应分支检查 Runner 注册命令里的--labels与runs-on是否一致缓存不生效每次都全量下载缓存 key 没跟着依赖变只写了固定字符串path与 Runner 上实际缓存目录不符key 里带上hashFiles(**/go.sum)依赖变了 key 自动失效在 Runner 上确认~/.cache/go-build等路径真实存在本地能跑Runner 上必挂环境不一致本机隐式依赖全局装的包、环境变量没写进 workflow用了latest这类漂移版本所有工具在 workflow 里显式安装并固定版本用同一个容器镜像本地复现 Runner 环境再排查本地想快速验证 workflow 对不对不必每次真 push可以参考仓库自带的调试方式见 docs/testing.md。能力速查表我想做 X用什么我想……用这个字段 / 工具每次提交都自动跑测试on: [push]steps只在 main 分支触发on.push.branches: [main]偶尔手动点一次运行on: workflow_dispatch多个任务按顺序执行needs: [前置任务]多系统 / 多版本并行测试strategy.matrix安全存密码、token${{ secrets.X }}仓库设置 → Secrets给某个步骤传变量env:缓存依赖加速构建actions/cache跨任务传构建产物actions/upload-artifact/actions/download-artifact构建并推送 Docker 镜像docker/login-actiondocker/build-push-action只在我自己的机器上跑Runner 注册--labels 自定义标签runs-on: 自定义标签失败时通知群里if: failure()run: curl ...Gitea 自己也是这么干活的想看真实案例直接翻 .github/workflows/ 里的十几个工作流文件。 下一步把测试、构建、部署写进一个 YAML交给 Gitea Actions你的提交记录从此自带绿灯。顺着这条流水线再往前一步——把推好的镜像自动部署到 Kubernetes那才是它真正的终点我们下篇见。【免费下载链接】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），仅供参考