如何搭建 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周三晚上十点热修上线你手动跑测试、打 tag、把包传到服务器——中间漏掉一条迁移命令生产库直接报错。这类事故很少是因为某一步多难而是步骤太多、全靠人记忆。把测试、构建、发布交给 Gitea Actions 这条自动化流水线持续集成就从口号变成了仓库里的一个 YAML 文件每次 push 后它自己把该干的活干完。Gitea Actions 运行列表页截图 触发与编排一次 push 之后发生什么这一节解决什么时候跑、按什么顺序跑的问题。Workflow 文件放在仓库的.gitea/workflows目录下.yml或.yaml结尾。触发器写在on字段里常用的一共有这些常用触发器对照触发器何时触发典型用途push代码推送到远端分支/标签上的日常验证pull_requestPR 创建或更新合入前的质量门禁release版本发布打包、发版通知scheduleCron 定时夜间回归、依赖巡检workflow_dispatch手动点击按钮重跑失败任务、一次性操作issue_commentIssue 下评论用口令式评论触发任务下面这段 YAML 只要 15 行就能让每次 push 到main自动跑完 Node.js 的测试测试通过后才进入打包阶段——这是一个典型的 Gitea 自动化测试部署起点on: push: branches: [ main ] jobs: unit: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci npm test package: needs: unit runs-on: ubuntu-latest steps: - run: echo unit 通过后才会执行needs是编排的核心package声明needs: unit只有unit成功后它才会启动unit失败则整个后续链跳过。反过来没有needs的 Job 之间是并行执行的于是可以这样拆一条 Gitea 构建流水线实战里常见的验证链三条验证 Job 同时开跑全部通过才进build整体耗时约等于最慢的那条而不是四条之和。Gitea Actions 执行界面Job 状态 Runner 与 Secrets环境隔离和密钥不落地这一节解决在哪台机器上跑、敏感信息怎么传的问题。Job 由 Runner执行 Job 的守护进程真正运行。接入步骤很短管理员在后台「服务 → Actions」勾选启用 Actions仓库「设置 → 功能」里打开 Actions在 Actions 页点「管理 Runner → 创建 Runner」拿到注册 token在目标机器按提示注册并启动 Runner 进程Gitea CI/CD 配置里有两种常见的运行方式直接跑在 Runner 主机上runs-on: ubuntu-latest跑在容器里runs-on: docker://node:20每个 Job 一个一次性容器装了什么依赖、缺了什么依赖都可控天然避免在我机器上能跑容器化还有一个好处镜像版本就是环境版本回滚时把runs-on的 tag 换回去即可。密钥不落地Secrets 注入部署口令、仓库注册表 token 这类东西永远不要写进 YAML。把它们存到仓库「设置 → Secrets」运行时再注入- name: 发布 env: DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }} VERSION: ${{ github.sha }} run: ./deploy.sh --key $DEPLOY_KEY --ver $VERSION${{ secrets.X }}只在 Runner 执行时展开成环境变量不进代码库、不进日志。另外每个 Job 会自动拿到一个GITEA_TOKEN用于checkout等步骤它的权限会被仓库/组织级别的策略硬限制——这块的设计细节可以看 Actions 令牌权限说明。Runner 注册后的状态页 集成质量门禁与镜像构建这一节解决流水线怎么接第三方工具的问题。接外部工具就两条路run里直接调命令行工具golangci-lint、ruff、pnpm audit 都行或者uses一个现成的 Action。质量门禁建议放在 PR 触发的 Job 里覆盖率没达标就让 CI 红掉比事后补扫省事。镜像构建是另一个高频场景把构建和推送串成一个 Job版本直接用 commit 短 hash保证可追溯jobs: image: runs-on: docker://node:20 env: USERNAME: ${{ secrets.REGISTRY_USER }} TOKEN: ${{ secrets.REGISTRY_TOKEN }} steps: - uses: actions/checkoutv4 - run: docker build -t myapp:${{ github.sha }} . - run: | docker login -u $USERNAME -p $TOKEN docker push myapp:${{ github.sha }}发 release 时把 tag 也打一份镜像比如myapp:${{ github.ref_name }}回滚就是拉旧 tag 重新部署不用再从 git 里翻历史。容器镜像构建 Job 的日志⚡ 提速与排障缓存、矩阵和日志这一节解决流水线跑得慢、失败又难查的问题。缓存让第二次跑快一半依赖下载通常占单 Job 的大头用actions/cache按锁文件指纹缓存依赖没变就直接命中- uses: actions/cachev4 with: path: ~/.npm key: npm-${{ hashFiles(package-lock.json) }} restore-keys: npm-用 matrix 跑多环境同一套测试要在多个 Node 版本、多个系统上跑时不要复制多份 Job用strategy.matrix展开jobs: test: strategy: fail-fast: false matrix: node: [ 18, 20 ] os: [ ubuntu-latest, windows-latest ] runs-on: ${{ matrix.os }} steps: - uses: actions/setup-nodev4 with: node-version: ${{ matrix.node }} - run: npm test维度取值组合数node18、202osubuntu、windows2合计 Job 数—4fail-fast: false表示某格失败不取消其他格方便一次看全所有兼容性问题。失败先看这三处不触发文件是否在.gitea/workflows、on里的分支是否匹配、仓库是否启用 Actions触发但 Job 不启动runs-on的标签没有对应在线 Runner启动但步骤失败打开 run 详情看对应 step 的日志定位到具体命令的退出码Job 日志详情页✅ 什么时候该上什么时候不必给个判断标准避免为了 CI 而 CI场景建议多人协作、PR 频繁上pushpull_request双触发加质量门禁有固定发布节奏、要回滚上release触发镜像/制品按 tag 归档个人玩具仓库不必手动测试比维护 YAML 更快单机部署、改动很少看情况一个定时备份 Job 就够了如果你已经在用 Gitea 托管代码Actions 是最顺手的补全件YAML 就在仓库里配置随代码 review环境与流水线一起版本化。先从push 自动跑测试这一个最小 Job 开始等它稳定再把构建、发布一格一格加上去——比一次性搭大流水线更容易落地也更少返工。【免费下载链接】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），仅供参考 如何搭建 Gitea Actions 自动化流水线
如何搭建 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周三晚上十点热修上线你手动跑测试、打 tag、把包传到服务器——中间漏掉一条迁移命令生产库直接报错。这类事故很少是因为某一步多难而是步骤太多、全靠人记忆。把测试、构建、发布交给 Gitea Actions 这条自动化流水线持续集成就从口号变成了仓库里的一个 YAML 文件每次 push 后它自己把该干的活干完。Gitea Actions 运行列表页截图 触发与编排一次 push 之后发生什么这一节解决什么时候跑、按什么顺序跑的问题。Workflow 文件放在仓库的.gitea/workflows目录下.yml或.yaml结尾。触发器写在on字段里常用的一共有这些常用触发器对照触发器何时触发典型用途push代码推送到远端分支/标签上的日常验证pull_requestPR 创建或更新合入前的质量门禁release版本发布打包、发版通知scheduleCron 定时夜间回归、依赖巡检workflow_dispatch手动点击按钮重跑失败任务、一次性操作issue_commentIssue 下评论用口令式评论触发任务下面这段 YAML 只要 15 行就能让每次 push 到main自动跑完 Node.js 的测试测试通过后才进入打包阶段——这是一个典型的 Gitea 自动化测试部署起点on: push: branches: [ main ] jobs: unit: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci npm test package: needs: unit runs-on: ubuntu-latest steps: - run: echo unit 通过后才会执行needs是编排的核心package声明needs: unit只有unit成功后它才会启动unit失败则整个后续链跳过。反过来没有needs的 Job 之间是并行执行的于是可以这样拆一条 Gitea 构建流水线实战里常见的验证链三条验证 Job 同时开跑全部通过才进build整体耗时约等于最慢的那条而不是四条之和。Gitea Actions 执行界面Job 状态 Runner 与 Secrets环境隔离和密钥不落地这一节解决在哪台机器上跑、敏感信息怎么传的问题。Job 由 Runner执行 Job 的守护进程真正运行。接入步骤很短管理员在后台「服务 → Actions」勾选启用 Actions仓库「设置 → 功能」里打开 Actions在 Actions 页点「管理 Runner → 创建 Runner」拿到注册 token在目标机器按提示注册并启动 Runner 进程Gitea CI/CD 配置里有两种常见的运行方式直接跑在 Runner 主机上runs-on: ubuntu-latest跑在容器里runs-on: docker://node:20每个 Job 一个一次性容器装了什么依赖、缺了什么依赖都可控天然避免在我机器上能跑容器化还有一个好处镜像版本就是环境版本回滚时把runs-on的 tag 换回去即可。密钥不落地Secrets 注入部署口令、仓库注册表 token 这类东西永远不要写进 YAML。把它们存到仓库「设置 → Secrets」运行时再注入- name: 发布 env: DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }} VERSION: ${{ github.sha }} run: ./deploy.sh --key $DEPLOY_KEY --ver $VERSION${{ secrets.X }}只在 Runner 执行时展开成环境变量不进代码库、不进日志。另外每个 Job 会自动拿到一个GITEA_TOKEN用于checkout等步骤它的权限会被仓库/组织级别的策略硬限制——这块的设计细节可以看 Actions 令牌权限说明。Runner 注册后的状态页 集成质量门禁与镜像构建这一节解决流水线怎么接第三方工具的问题。接外部工具就两条路run里直接调命令行工具golangci-lint、ruff、pnpm audit 都行或者uses一个现成的 Action。质量门禁建议放在 PR 触发的 Job 里覆盖率没达标就让 CI 红掉比事后补扫省事。镜像构建是另一个高频场景把构建和推送串成一个 Job版本直接用 commit 短 hash保证可追溯jobs: image: runs-on: docker://node:20 env: USERNAME: ${{ secrets.REGISTRY_USER }} TOKEN: ${{ secrets.REGISTRY_TOKEN }} steps: - uses: actions/checkoutv4 - run: docker build -t myapp:${{ github.sha }} . - run: | docker login -u $USERNAME -p $TOKEN docker push myapp:${{ github.sha }}发 release 时把 tag 也打一份镜像比如myapp:${{ github.ref_name }}回滚就是拉旧 tag 重新部署不用再从 git 里翻历史。容器镜像构建 Job 的日志⚡ 提速与排障缓存、矩阵和日志这一节解决流水线跑得慢、失败又难查的问题。缓存让第二次跑快一半依赖下载通常占单 Job 的大头用actions/cache按锁文件指纹缓存依赖没变就直接命中- uses: actions/cachev4 with: path: ~/.npm key: npm-${{ hashFiles(package-lock.json) }} restore-keys: npm-用 matrix 跑多环境同一套测试要在多个 Node 版本、多个系统上跑时不要复制多份 Job用strategy.matrix展开jobs: test: strategy: fail-fast: false matrix: node: [ 18, 20 ] os: [ ubuntu-latest, windows-latest ] runs-on: ${{ matrix.os }} steps: - uses: actions/setup-nodev4 with: node-version: ${{ matrix.node }} - run: npm test维度取值组合数node18、202osubuntu、windows2合计 Job 数—4fail-fast: false表示某格失败不取消其他格方便一次看全所有兼容性问题。失败先看这三处不触发文件是否在.gitea/workflows、on里的分支是否匹配、仓库是否启用 Actions触发但 Job 不启动runs-on的标签没有对应在线 Runner启动但步骤失败打开 run 详情看对应 step 的日志定位到具体命令的退出码Job 日志详情页✅ 什么时候该上什么时候不必给个判断标准避免为了 CI 而 CI场景建议多人协作、PR 频繁上pushpull_request双触发加质量门禁有固定发布节奏、要回滚上release触发镜像/制品按 tag 归档个人玩具仓库不必手动测试比维护 YAML 更快单机部署、改动很少看情况一个定时备份 Job 就够了如果你已经在用 Gitea 托管代码Actions 是最顺手的补全件YAML 就在仓库里配置随代码 review环境与流水线一起版本化。先从push 自动跑测试这一个最小 Job 开始等它稳定再把构建、发布一格一格加上去——比一次性搭大流水线更容易落地也更少返工。【免费下载链接】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），仅供参考