简要介绍如何在KubeSphere中使用Jenkins基于用户选择的不同GitLab工程模块利用Git进行动态的代码下载和编译构建，将多条流水线缩减为一条，减少Jenkins流水线的开发与维护成本。

背景

在利用Nacos与KubeSphere创建多套开发与测试环境一文中介绍了部门基于KubeSphere和Nacos来动态的创建多套开发与测试环境，此种方式虽然在公司内部使用起来很灵活，但当需要交付给客户时会存在如下问题导致KubeSphere不适合部署给客户使用:

  1. 客户使用环境的网络无法接入公司网络，无法下载代码
  2. 客户使用环境不一定有Kubernetes环境，无法部署pod节点

由于docker的安装相对Kubernetes而言会简单很多，故决定采用docker容器的形式在客户现场部署运行软件，相关流程如下： 适应客户使用环境的软件部署流程

实际使用时在公司内部提前打包好对应的docker镜像并导出，然后在客户环境导入对应的docker镜像并运行即可，通过此种方式可有效的避免对于公司内部特定环境和配置的依赖。

为实现上述目的，可通过docker save先导出镜像，然后使用Jenkins的archiveArtifacts功能导出镜像文件即可，这样看来问题似乎很容易解决，直接修改原有的Jenkins流水线即可。由于不同项目模块在使用上会有细微的差异，同时处于简化开发和维护的考虑，目前部门的使用方式是每个工程对应一条Jenkins流水线，这样导致每条流水线都需要修改，工作量且不利于后续的扩展！

每个工程模块均对应一条流水线

基于上述原因，最终的实现方案如下

实现方案

部门内部研发测试使用的构建流水线与要交付给客户的产品构建流水线分开创建与使用，且交付构建的流水线数目要尽可能少，便于后续维护与定制化扩展

下图展示了更详细的使用流程，在该图中引出了我们的问题

问题

如何在Jenkins中只通过一条流水线根据用户选择的工程模块来动态的下载代码?

flowchart TD subgraph A1(开始构建) -->A2{选择对应参数} A2 -->|用于获取端口等配置| A3[打包环境] A2 --> A4[选择工程]:::checkstyle A2 -->|对应工程Gitlab分支| A5[选择分支]:::checkstyle A4 --> A6[[Checkout代码]]:::checkstyle A5 --> A6 A6 --> |更新yaml等配置文件| A7[更新配置] A3 --> A7 A7 --> A8[[代码编译]] A8 --> A9[(导出jar文件)] A8 --> A10[镜像构建] A10 --> A11[(导出镜像)] A9 --> A12(((构建结束))) A11 --> A12 end subgraph B1(导入镜像) --> B2[文件校验] --> B3[[容器部署]] end subgraph C1(导入jar) --> C2[文件校验] --> C3[[运行jar]] end A11 -->|docker方式部署| B1 A9 --> |直接运行jar文件| C1 classDef checkstyle fill:#6bacf2,color:#ffffff,font-weight:bold

解决思路

由于最初是每个工程项目都有一个单独的Jenkins流水线，故在通过Git下载代码时采用的是类似下图的直接写死Gitlab工程仓库地址的方式，很明显此种方式不满足要求。

stage('拉取代码') {
    agent none
    steps {
        // git仓库地址直接以字符串方式写死
        git(credentialsId: 'gitlab-account', url: 'http://gitlab.xxx.com/lucumt-group/system.git', branch: '$BRANCH_NAME', changelog: true, poll: false)
    }
}

在网上搜索后发现一篇文章dynamically-selecting-git-repo-in-jenkins-job,其采用parameters实现，将Gitlab仓库的地址存储在一个变量中，然后Git下载时实际计算变量值并进行下载。此方案看起来符合要求，进一步查找后发现parameters本身无法直接修改1，不满足使用要求。

由于先前对代码分支名称的获取可通过$BRANCH_NAME来实现，自己尝试采用类似的方式来验证，最终找到了符合要求的实现方案

采用不同方式尝试在jenkins中实现动态下载

下图展示了完整的使用链路，可发现其实现复杂度不是很高

jenkins动态下载代码图解

展示效果

运行结果如下：

采用jenkins动态下载代码并构建的示例

相关流水线参考如下：

流水线 作用 备注
lucumt-server-image-build.groovy 服务器端打包流水线，产出物为docker镜像
lucumt-front-image-build.groovy 前端打包流水线，产出物为docker镜像
lucumt-server-jar-build.groovy 服务器端打包流水线，产出物为jar文件 可直接用Java运行该jar文件
lucumt-front-dist-build.groovy 服务器端打包流水线，产出物为zip文件 nodejs编译后的文件压缩

  1. https://stackoverflow.com/questions/61789938/change-jenkins-param-variable-value ↩︎