从 GitLab 集中式管道转向 Actions，习惯了模块化做法的开发者会直接碰壁。在 GitLab 里，一个中央“流水线”仓库作为单一事实来源，各项目只需通过 include 引用，就能消除重复配置，保证一致性并降低维护负担。可一到新平台，这套逻辑行不通了——工作流通常定义在每个仓库的 .github/workflows 目录里，缺少直接等价于 include 的机制，集中化必须重新想辙。

第一个难点出在可重用工作流的作用域限制。虽然能用 uses 从中央仓库引用工作流，但这些工作流要么得放在公开仓库，要么得放在同一仓库内。没有标签化的版本管理，一更新就容易“炸”——平台默认拉最新提交，中央工作流改了，依赖项目就可能行为不一致。简单说，少了像原平台那样通过稳定版引用带来的安全感。

第二个摩擦点是 include 和 uses 的本质差异。前者的 include 将被包含文件视为本地上下文的一部分，集成顺滑；而后者的 uses 引用的是外部工作流，运行在独立作用域内，输入输出必须显式定义。比如，一个 CI 作业引用了共享脚本，如果脚本依赖的环境变量没有通过接口传过去，迁移后就可能直接失败。这意味着原本透明式的上下文共享，到新环境里全得显式管理。

怎么破解？实战中不得不走混合路线。第一种方案是复合动作，能把多个步骤打包成一个可重用单元，封装复杂逻辑，减少重复。但输入输出需要小心定义，比如构建容器镜像的复合动作，得把 Dockerfile 路径作为输入、把镜像标签作为输出，确保在不同项目中兼容。

另一种方案是借助平台应用在多个仓库中强制执行 CI/CD 配置。这条路能带来集中控制，但管理开销不小——App 需要权限并在所有目标仓库安装，更适合合规要求严格的组织，小团队用起来可能大材小用。

总的来看，在新平台中复制老平台的集中化 CI/CD 并非不可能，而是要灵活组合可重用工作流、复合动作和版本管理策略。具体怎么选，取决于组织的规模与复杂度。