Gitea Actions 从零跑通3 步搭好你的自动化测试与部署流水线【免费下载链接】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周五傍晚你合掉最后一个 PR开始手动三连本地跑一遍测试、打个发布包、SSH 到服务器替换文件。跑到第二步终端报了一行红字你盯着它脑子里全是这次上线会不会又翻车。Gitea Actions 干的就是把这条人肉链路变成自动流水线代码一推上去自动化测试、构建、部署依次执行人只负责看结果不负责踩雷。它直接内置在你的 Gitea 实例里不用额外买服务也不用改仓库结构。快速上手让第一条流水线跑起来先搞清楚两个角色。Workflow 是一张工厂流程图用 YAML 描述先干什么、后干什么Runner 是产线上干活的工人真正执行命令的机器。Gitea 负责派单Runner 负责干活。第 1 步确认 Actions 已开启。管理员后台进管理面板 → 配置 → Actions确认功能处于启用状态。较新版本默认就是开的。对应配置在 custom/conf/app.example.ini 的[actions]段默认 Workflow 目录同时扫描.gitea/workflows和.github/workflows两处见 modules/setting/actions.go。第 2 步注册一台 Runner。在仓库或组织页面的 Actions 处点创建 RunnerGitea 会给你一个令牌和一条注册命令。在任意一台空闲机器上# 用创建时给出的令牌注册令牌只显示一次复制下来 gitea-runner register --instance https://your-gitea.example.com \ --token 令牌 --name build-box --labels docker # 注册完直接前台跑起来方便观察输出 gitea-runner daemon第 3 步写第一个 Workflow。在仓库根目录建.gitea/workflows/hello.ymlname: First Pipeline # 显示在 Actions 页面的流程名 on: push: branches: [main] # 只在 main 分支推送时触发 jobs: smoke: runs-on: docker # 必须匹配 Runner 的标签 steps: - uses: actions/checkoutv4 # 先把代码拉到工作目录 - run: echo pipeline is alive推上去Actions 页面会多出一行记录点开能看到绿色对勾和每一步的日志。到这一步你已经具备了完整流水线的全部零件。实战Python 项目的测试→构建→发布流水线下面是一条有真实业务价值的流水线push 到 main 或打 tag 时先跑测试测试过了才构建 wheel 包并上传 Artifact最后把部署这一步拆成独立 job只在 main 分支执行。阶段之间的依赖用needs表达上游挂了下游不会白跑。name: Release Pipeline on: push: branches: [main] tags: [v*] jobs: test: runs-on: docker steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: { python-version: 3.12 } - run: | pip install -e . pytest pytest tests/ -q build: needs: test # 测试不通过构建直接跳过 runs-on: docker steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: { python-version: 3.12 } - run: | pip install build python -m build --wheel - uses: actions/upload-artifactv4 with: name: dist path: dist/*.whl # 产物挂到本次运行上供后续下载 deploy: needs: build if: github.ref refs/heads/main # 只有 main 分支才部署tag 只发 PyPI runs-on: docker environment: production # 绑定环境可挂审批与变量 steps: - uses: actions/download-artifactv4 with: { name: dist } - name: Ship to server env: SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }} # 密钥运行时注入不落盘 run: | echo $SSH_KEY key chmod 600 key scp -i key dist/*.whl deploy10.0.0.7:/srv/app/ ssh -i key deploy10.0.0.7 pip install --force-reinstall /srv/app/$(ls dist | head -1)几个值得记住的点needs是阶段闸门。deploy依赖buildbuild依赖test任何一环失败后面自动短路。产物靠 Artifact 传递。Runner 之间不共享磁盘upload-artifact/download-artifact是跨 job 传文件的正规通道。environment: production让部署挂到生产环境上可以在环境配置里加审批人和专属变量等于给上线加了一道人工锁。进阶技巧让流水线又快又稳用缓存给流水线提速。何时用每次运行都花几分钟装依赖时。写法把依赖装进一个固定目录再用缓存按锁文件哈希存取。效果依赖没变的运行从全量安装变成秒级恢复典型能省一半以上时间。- uses: actions/cachev4 with: path: ~/.cache/pip key: pip-${{ hashFiles(**/uv.lock, **/requirements.txt) }} # 锁文件一变键就变 restore-keys: | pip- # 键没命中时退回最近的缓存拆 job 并行用 if 做条件闸门。何时用单 job 串行跑太久或者有些步骤只在特定场景需要时。写法把代码检查和单元测试拆成两个并列 job没有needs关系就并行执行部署类步骤用if限定分支。效果总时长取最长一条支路而不是各段之和且 tag 构建不会误触部署。上面实战例子里if: github.ref refs/heads/main就是最简的条件执行。密钥安全管理secrets 而不是明文。何时用流水线要碰部署密钥、发布令牌、第三方 API 时。做法在仓库或组织的 Secrets 设置里存入DEPLOY_SSH_KEYYAML 里用${{ secrets.名称 }}引用。注意三条纪律密钥只在 Runner 运行时注入环境变量不会写进代码或日志按最小权限分环境存放测试密钥放仓库级生产密钥放组织级并配 environment密钥一旦提交进仓库历史或贴进日志立即作废重发。踩坑排查从症状直接找答案症状 1推了代码Actions 页面毫无动静。按顺序查三处Workflow 文件是否放在.gitea/workflows/下放错目录 Gitea 根本看不见on里的分支规则是否覆盖了你推送的分支runs-on的标签是否与某台在线Runner 的标签完全一致。三者全对却还不动时看一眼提交信息里有没有[skip ci]这类字样它会被 Gitea 直接跳过跳过词列表同样定义在 modules/setting/actions.go。症状 2Runner 注册成功任务却永远排队。大概率是 Runner 进程没跑或断网。到那台机器上确认daemon进程活着、网络能回连 Gitea 实例重启 daemon 后任务通常几十秒内被领走。症状 3缓存明明配了每次还是全量下载。九成是key的写法问题键里要么没包含依赖清单锁文件没变却每次命中旧缓存要么写进了run_id这类每次都变的值永远命中不了。让键只跟随锁文件哈希走恢复失败时用restore-keys兜底。症状 4日志里密钥明文泄露了。先做最坏假设立刻作废该密钥、重新生成、只存进 Secrets。复盘时重点看是不是自己echo了环境变量或是报错信息把配置整段打印了出来。密钥一旦进过日志就没有撤回一说只能换。收尾Gitea Actions 把测试、构建、部署写进一个 YAML 文件Runner 接单执行Artifact 传递产物needs和if控制节奏secrets 守住敏感信息。上手只要三步剩下的时间都该花在把流水线调得又短又稳上。实例配置参考custom/conf/app.example.ini[actions]段默认行为源码modules/setting/actions.goRunner 侧逻辑modules/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考