.cnb.yml中的include、reference产生的副作用太大，生成的结果不够清晰，需要在执行后才能知道当前流水线合并后生成的执行文件具体内容。

reference与yaml的锚点类似。

事实上直接使用include语法即可，个人建议可以每个文件都像 github action单文件那样定义，各自工作互不打扰，而不必纠结在配置合并后的执行效果。如果想要查看效果，代码提交之后，在预览中也是可以看到的(下图标号1)。

参考示例：https://cnb.cool/opsre/JenkinsGuide/-/blob/main/.cnb.yml

补充一句：cnb这里的语法还支持模板化引用。据我了解github action应该是不支持的(也可能是我不了解)。比如你可以把一些公共的动作放到一个模板库里，然后其他需要运行的仓库直接include即可。如下图标号3：

include语法的副作用太大了，会导致只有执行时候才知道，具体执行的流水线内容。

这对于自动化管理并不友好。
多文件的虽然会导致自动化配置东一处西一处，复用率也低，但起码也所见即所得。

又没有更友好的方式呢？

include语法的副作用太大了，会导致只有执行时候才知道，具体执行的流水线内容。

@Mr.d(嗯嗯) 点击预览是可以看到流水线完整内容的

如下图，你想拆分维护是完全可以的。

简单概括：github 默认加载 workflows下所有的yml配置。cnb你可以按需include。运行机制是一致的。

好的，看到了。

最后意思还是全部读到了.cnb.yml这个文件是吧？预览时候上千行也不好看吧？

好的，看到了。

最后意思还是全部读到了.cnb.yml这个文件是吧？预览时候上千行也不好看吧？

@Mr.d(嗯嗯) 需要预览的时候，你可以用预览，不需要预览，你可以看单文件。二者是一样的。

好的，通过这种方案也可以实现github的多文件部署方案。

还需要试试多文件嵌套include等复杂流水线。

如上述回答的，当前的include、reference语法完全可以达到拆分工作流文件的效果，reference与yaml的锚点类似是因为本来就是为了解决yaml的锚点不能跨文件使用的问题