跳到主要内容

github CI/CD

  • Github Actions 是 Github 在 2019 年才推出的 CI/CD 服务
  • 在 GitHub CI(GitHub Actions)里做“推 tag 自动发布 Release/产物
  • 通过YAML配置文件,开发者可以定义触发条件和执行步骤

基本概念

  • workflow(工作流程):指整个持续集成的流程,包含执行脚本任务、执行触发事件等

  • Events (事件):触发流程的钩子,例如提交代码触发,新建 Issues 触发等等。

  • Jobs (任务):每一个工作流程包含一个或多个任务,任务按顺序执行,每一个任务都会执行 shell 脚本。

  • Steps (步骤):每一个 Job 包含一个或多个 Step, Step 按顺序执行。

  • Actions(动作): 每一个 Step 包含一个或多个 Action, 按顺序执行。

  • Runners(执行环境): workflow 运行时的服务器,每一个 Runner 可以运行一个 Job.、

    • Runners可以执行各种 shell 脚本

相关yaml配置说明​

字段类型作用常见写法/示例备注/坑
namestring工作流在 Actions 页面显示的名称name: Release不写也行,会用文件名
onobject / string / array触发条件(事件)见下表最核心
permissionsobject / string给 GITHUB_TOKEN 配权限permissions: { contents: write }建议“最小权限”原则;不配可能导致 release/写入失败
envobject工作流级环境变量(对所有 jobs 生效)env: { NODE_ENV: production }env 可多层:workflow/job/step,越往下优先级越高
defaultsobject默认 shell、默认工作目录等defaults: { run: { shell: bash } }常用于统一 shell、workdir
concurrencyobject / string并发控制:同一组只跑一个,新的会取消旧的concurrency: { group: release-${{ github.ref }}, cancel-in-progress: true }防止重复发版/重复部署
run-namestring自定义每次运行的“实例名”run-name: Release ${{ github.ref_name }}Actions 列表里更好辨认
jobsobject具体执行任务集合jobs: { build: ... }必填(否则没事可做)

on 触发器(最常用事件)​

写法作用示例典型用途/说明
on: pushpush 触发(默认所有分支)on: push简单 CI
on: pull_requestPR 触发on: pull_requestPR 检查、测试
on: workflow_dispatch手动触发(按钮)on: workflow_dispatch手动发布、带参数
on: releaseGitHub Release 事件on: { release: { types: [published] } }发布后触发,比如部署
on: schedule定时任务(cron)on: { schedule: [{ cron: "0 2 * * *" }] }夜间构建、巡检
on: push: tags推 tag 触发on: { push: { tags: ["v*"] } }最常见发版方式
on: push: branches推某些分支触发on: { push: { branches: ["main"] } }主分支合并后构建部署
on: pull_request: paths仅某些路径变化触发on: { pull_request: { paths: ["src/**"] } }降低不必要 CI
on: push: paths-ignore忽略路径变化on: { push: { paths-ignore: ["docs/**"] } }文档改动不跑 CI

permissions 权限​

  • permissions 影响:创建 Release、上传附件、推 tag、改 PR 状态、发评论、访问 Packages 等。
scope常见值用途什么时候需要
contentsread / write读写仓库内容;创建 release、推 tag、上传 release asset发版一般需要 write
packagesread / writeGitHub Packages(Docker/包)推镜像/发布包
actionsread / write操作 Actions(较少用)少数高级场景
checksread / write创建/更新 checks(状态检查)自定义检查上报
pull-requestsread / writePR 评论、标签、合并相关自动评论/自动标记
issuesread / writeissue 评论、创建等自动提 issue/评论
id-tokenwriteOIDC 联邦认证(云登录)上云(AWS/GCP/Azure)免密
statuseswritecommit status(老式状态)某些集成还用
security-eventswriteCode scanning 结果上报安全扫描上报

jobs 层级字段​

字段类型作用示例备注/坑
jobs.<job_id>objectjob 唯一标识(yaml key)build:id 只能用字母数字下划线
namestringjob 显示名name: Build & Test不写默认用 job_id
runs-onstring/arrayRunner 环境runs-on: ubuntu-latest也可矩阵:[self-hosted, linux]
needsstring/array依赖其他 jobneeds: [test]控制执行顺序
ifstring条件执行if: startsWith(github.ref, 'refs/tags/')表达式语法 ${{ }} 里写或省略均可
permissionsobject覆盖 workflow 级权限permissions: { contents: write }只给发版 job 提权更安全
envobjectjob 级环境变量env: { FOO: bar }
concurrencyobjectjob 级并发控制同上
timeout-minutesnumber超时timeout-minutes: 30防止卡死
strategyobject矩阵构建、多平台见下表
stepsarray具体步骤- uses: ...job 必须有 steps

github ci自动发布流程​

  • 在GitHub仓库中,创建一个名为.github/workflows的文件夹,并在其中添加一个.yml文件

  • 大部分情况下都是在ghutb中“自动生成模板 + 你再自己改”

  • 目前让ai写github ci的配置即可

1、推送 v* tag 自动创建 GitHub Release,并上传构建产物(最常用)​

文档:https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax

当提交tag,就会触发github ci脚本

  • 文件:.github/workflows/release.yml
  • 触发方式:git tag v1.2.3 && git push origin v1.2.3