gitlab ci 入门，一个 yml 加一个 runner 就能跑

代码推上去，还要手动 npm run build、手动传服务器，一天来五回谁都烦。gitlab ci 的玩法是在仓库根目录放一个 .gitlab-ci.yml，GitLab 检测到提交就按里面定义的阶段自动派活，真正干活的机器叫 runner。

最小可跑的 yml

stages: [build, test]  build_job: {stage: build, script: [npm ci, npm run build]}  test_job: {stage: test, script: [npm test]}

stages 定顺序，前面阶段挂了后面就不跑。job 名字随意，stage 指明属于哪个阶段，script 里就是要执行的命令。yml 对缩进敏感，报错先检查空格是不是混了 tab。

runner 注册一下才能动

没有 runner 的仓库会一直卡在 pending。自己有服务器就在上面装 gitlab-runner，注册时填 GitLab 实例地址和 token，executor 选 shell 简单直接，选 docker 环境干净。不想维护机器就用 GitLab 托管的共享 runner，多数情况公共项目的免费额度跑日常构建够用。

控制触发、变量和缓存

全量跑太浪费，用 rules 控制：只在 main 分支或打 tag 时构建。服务器地址、密钥这类东西别写死在 yml 里，放到项目 Settings 的 CI/CD Variables，日志里会自动打码。再配个 cache 缓存 node_modules，不然每个 job 都重新拉依赖，构建时间从一分钟变十分钟。

判断：小团队两三个项目，一台 4 核 8G 的机器跑 shell executor 足够；项目多了再上 docker executor 做环境隔离，别一上来就堆几十个 job 的复杂流水线，维护成本先拖垮人。