路径过滤触发是什么
只对改动的目录或文件类型触发对应流水线：文档改动不跑构建、后端改动不跑前端打包。价值在减少无关运行与排队，但过滤规则必须覆盖真实依赖面：lockfile、基础配置、共享工具这些容易被漏掉的路径，改动了却不触发验证。过滤之后仍要保留一个必需检查，否则绕过路径的变更可能带着红灯合并。
基本信息
| GitLab | rules:changes 基于推送的改动文件列表判断 |
|---|---|
| GitHub | on.push.paths 与 paths-ignore，push 与 PR 分别配置 |
| 价值 | 减少无关运行，降低排队与成本 |
| 基准差异 | GitLab changes 的比较基准随场景不同，需分场合验证 |
| 兜底 | 保留一个不受过滤影响的必需检查 |
典型使用场景
- 单仓多项目：按目录切分不同流水线。
- 文档与配置：不触发构建与测试。
- 硬件相关：只在驱动目录改动时跑硬件测试集。
- 前端后端分离：各自改动触发各自的流水线。
- 成本控制：减少全量运行次数与排队时间。
GitHub
GitHub
on:
pull_request:
paths: ['src/**', 'tests/**', 'package.json']GitLab
GitLab
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
- src/**/*过滤键对照
| 平台 | 键 | 说明 |
|---|---|---|
| GitHub | paths | 只在这些路径改动时触发 |
| GitHub | paths-ignore | 这些路径之外才触发 |
| GitLab | rules:changes | 基于改动的文件列表判断 |
过滤后仍需保留一个必需检查：否则绕过路径的变更可能带着红灯合并。
GitLab changes 的比较基准随场景不同，分支推送与合并请求两类的关键门禁都要验证过。
把依赖面写进路径列表：lockfile 与公共目录属于共享影响，不能被过滤掉。
组合条件更安全：路径与事件类型同时判断，例如只在合并请求且改动源码时运行。
大型仓库按目录分流水线：路径规则与标签叠加，避免一个文件改动拉起所有流水线。
对过滤行为做冒烟：专门改一次文档、改一次源码，验证两类触发都符合预期。
文档变更也留最小检查：拼写与链接检查成本低，完全无检查的改动容易被忽视。