并在chart阶段依次执行在项目ci-cd.yaml文件的resourcePlugins参数中定义好的插件（enable为false则不执行），如果找到的是第一种插件则执行对应的shell脚本，如果找到的是第二种插件，则直接复制插件目录中所有yaml文件到当前Chart镜像的template目录中。（上面命令最后面的kube-config文件就是java-sample项目中wydevops/dep

那么Java项目的编译是在哪里调用的呢？遇到某具体项目，可能需要通过向ci-cd-config.yaml配置文件添加新的参数和值，最终注入到ci-cd.yaml文件中，然后开发人员在项目中的wydevops/shell目录中提供某个功能扩展点的项目级实现，在该实现中读取注入的新参数并进行相应的操作——这种强大灵活的扩展性是wydevops的架构设计如此优秀带来的福利之一。标记2的红框中是wydev

在本文之前我已经写了12篇与wydevops相关的文章，介绍了wydevops从初始化到Docker镜像打包，再到chart镜像打包的大致过程，重点介绍了wydevops的参数映射机制、三级功能扩展机制、调用链机制、资源生成器插件机制等核心技术和关键规则，并以Java语言项目为例对这些重要功能进行了演示说明，这些示例充分的展示了：在团队预置好参数定义的情况下，业务开发人员可轻松具备无需太多配置甚至

pom.xml文件中的cicdName参数是个自定义的参数（熟悉maven pom.xml文件的人应该知道），根据params-mapping-in-xml-file.config文件中的配置，我们知道该参数值（唯一DevOps）被赋值给了配置模板文件_ci-cd-template.yaml中的globalParams.name参数。这里截取了java-sample项目中pom.xml文件的部分内

在实际项目部署过程中，是使用了另一个wydevops的组件："wydevops微服务管理平台"，用户通过该平台提供的UI界面上传wydevops生成的离线安装包，该平台自动解析离线安装包中的参数并通过界面展示给用户，用户可在界面上对各种参数进行修改，修改完毕后该安装器将使用用户动态设置的参数值完成微服务安装。如果原来就存在该配置节，则会进行合并处理：插入不存在的参数及其值，存在的参数其值保持不变（

这种场景下wydevops为你提供了本地第三方镜像缓存机制，只要你在本地构建中使用了第三方镜像（默认只缓存从公网拉取的，私库拉取的不会缓存），则wydevops会在指定的目录中保存这些第三方镜像的导出文件，并且在拉取镜像时会优先查询本地镜像缓存目录中是否存在目标镜像，如果存在则直接使用docker load命令加载到本地docker环境中。上图1处，我们看到出现了两个新文件，名称中包含-base-

ci-cd.yaml: 该文件是所有配置项解析处理后的标准文件.其内存放了5个构建阶段最终的所有配置参数. 当因配置错误中断执行后,我们想修改配置后从报错的阶段开始继续运行后面的过程时, 不能去修改ci-cd-config.yaml里面的参数,而要修改ci-cd.yaml中的参数才能其作用. 因为接续执行后面过程时-c标志会被删除, 此时不会执行从ci-cd-config.yaml读取参数的过程了

在实际项目中，我们首先需要定义好ci-cd.yaml文件的内容，这个文件也是ci-cd-template.yaml文件的标准模板（ci-cd-template.yaml文件的内容必须是ci-cd.yaml文件的全量内容）。一般情况下，项目中配置好ci-cd-config.yaml文件，工具集读取ci-cd-config.yaml中的参数值覆盖模板文件_ci-cd-config.yaml文件中的参数