Gitlab-ci自动识别Maven变更子模块并推送docker镜像的方法与流程

本发明涉及gitlab-ci进行docker镜像自动化构建领域，更具体的说是涉及gitlab-ci自动识别maven变更子模块并推送docker镜像的方法。

背景技术：

docker容器作为实践devops的一个重要工具越来越受开发者的喜爱，gitlab提供了免费的代码管理服务，同时gitlab-ci还提供了强大的自动化ci/cd(continuousintegration、delivery&deployment，持续集成/持续交付)流程功能，现在大多数开发者会选择采用gitlab-ci在代码提交到发布库时触发自动构建及推送docker镜像的方法进行容器应用自动化构建。

对于基于maven多模块搭建项目，通常情况下，我们在gitlab-ci构建阶段将各子模块编译后结果依次推送到docker镜像仓库中，虽然该次代码提交可能只涉及到1个或者少量几个子模块的变更，也需要将所有子模块编译结果推送到docker仓库中，由于实际工作中我们的项目规模大，子模块较多，且打包后文件比较大，将它们全部推送到docker镜像仓库时会占用相当长的时间，影响后续工作的执行，也会产生不必要的资源占用及空间浪费。

技术实现要素：

本发明的目的在于提供gitlab-ci自动识别maven变更子模块并推送docker镜像的方法，以期解决背景技术中的问题。

为了实现上述目的，本发明采用以下技术方案：

gitlab-ci自动识别maven变更子模块并推送docker镜像的方法，包括以下步骤：

s1：进行常规的gitlab-ci配置，包括管理页面中gitlabrunner、用户账号配置；

s2：在项目的配置文件.gitlab-ci.yml中进行自动识别变更需要的变量定义；

s3:在.gitlab-ci.yml脚本中的job定义部分，在执行项目整体编译完成后，执行项目整体编译，产生正确的编译后结果；判断预定义变量ci_commit_message是否以执行全部推送标记开头，如是则项目.gitlab-ci.yml脚本中的job部分：将所有子模块编译后结果推送到docker镜像仓库；如不是项目.gitlab-ci.yml脚本中的job部分：执行gitshow命令，使用预定义变量ci_commit_sha,汇总出本次提交受影响的子模块列表，按列表依次将受影响子模块编译后结果推送到docker镜像仓库。

所述s2包括以下步骤：

s2-1:在.gitlab-ci.yml脚本中的variables变量定义部分:根据模块结构定义各子模块对应代码仓库相对路径的变量；

s2-2:定义依赖公共模块变量的相关变量。

所述s2-1包括：

s2-1-1:对于普通子模块定义变量规则为：前面是变量，后面是其对应代码仓库相对路径；

s2-1-2:对于公共模块与s2-1-1一样，定义变量的前面是变量，后面是其对应代码仓库相对路径。

所述s3包括：

s3-1:利用预定义变量ci_commit_message，判断其是否以一个需要全部推送的标记，在提交代码时约定注释的前缀增加特殊标记开头,如是则将每个子模块编译后结果推送到docker镜像仓库，结束脚本执行；如不需要整体推送则执行s3-2；

s3-2:执行gitshow命令，使用预定义变量ci_commit_sha，获得本次提交所影响的所有代码的文件路径，然后从中依次判断是否包含我们在第一步设置的子模块路径变量，如包含普通模块，则将该模块添加到待推送推送模块列表中，如包含公共模块则将其依赖的所有子模块添加到待推送推送模块列表中，然后将待推送模块列表去重，最后按照此列表依次将其中子模块的编译结果推送到docker镜像仓库。

本发明与现有技术相比具有的有益效果是：

特别对于现今项目更多采用微服务方式，模块划分得更细粒度，子模块数量必然会很多，采用本方法后效果明显，极大节约了推送docker镜像的时间，也节省了镜像仓库的空间要求。提高了项目开发的效率。

附图说明

图1示出了基于maven多模块结构及依赖关系示意图；

图2示出了本发明的流程示意图。

具体实施方式

下面结合实施例对本发明作进一步的描述，所描述的实施例仅仅是本发明一部分实施例，并不是全部的实施例。基于本发明中的实施例，本领域的普通技术人员在没有做出创造性劳动前提下所获得的其他所用实施例，都属于本发明的保护范围。

实施例1:

通常利用gitlab-ci进行构建时，gitlabci主要用于管理构建状态，因此，运行构建任务一般交给gitlabrunner来做，这就必然会使用.gitlab-ci.yml来配置，告诉ci用需要做哪些操作，这个文件位于项目在代码仓库的根目录下，当有新内容push到代码仓库，或者有代码合并后，gitlab会查找是否有.gitlab-ci.yml文件，如果文件存在，runners将会根据该文件的内容开始build本次commit。至于gitlab服务的安装、runner的设置等都跟通常操作一样，不是本文讨论的重点。

对于maven多模块项目，通常的做法是在.gitlab-ci.yml配置中，首先对整个项目编译，然后依次将各个子模块的编译结果推送到docker镜像仓库中去，要想达到只推送受影响的子模块编译结果到docker镜像仓库，其问题的实质就是解决在gitlabrunner在执行阶段如何识别哪些子模块在本次提交中发生了改变，然而gitlab-ci默认的预定义变量中没有本次影响的子模块的定义，但是从9.0版后提供了：ci_commit_sha(本次提交的版本号)，10.8版本后提供了ci_commit_message(完整的提交消息)，利用他们，我们就可以实现目标。

本发明实施例提供了一种gitlab-ci自动识别maven变更子模块并推送docker镜像的方法：

下面参照图2流程示意图将具体描述执行步骤：

s1：进行常规的gitlab-ci配置，包括管理页面中gitlabrunner、用户账号等等配置；

s2：在项目的配置文件.gitlab-ci.yml中进行自动识别变更需要的变量定义，图1示出了基于maven多模块结构及依赖关系示意图，包含了maven多模块的构成可能，我们以此图例说明具体的定义。

s2-1:在.gitlab-ci.yml脚本中的variables变量定义部分:根据模块结构定义各子模块对应代码仓库相对路径的变量。

s2-1-1:对于普通子模块定义变量如：sub1module1：/sub1module1/前面是变量，后面是其对应代码仓库相对路径，

s2-1-2:对于公共模块与s2-1-1一样，定义变量如：sub2common:sub1module3/sub2common/前面是变量，后面是其对应代码仓库相对路径

s2-2:定义依赖公共模块变量的相关变量，如common_dependency：sub1module1,sub2module1,sub2module2前面是变量名，后面是该公共模块改变将影响到的子模块，注意这里需要根据项目结构配置会进行发布的最终子模块，例如sub2common只是公共包不进行发布使用，则不需要配置其中，各模块用逗号分隔

s3:在.gitlab-ci.yml脚本中的job定义部分，在执行项目整体编译完成后，依赖上述变量进行逻辑控制

s3-1:利用预定义变量ci_commit_message(完整的提交消息)，判断其是否以一个需要全部推送的标记(为了处理虽然只是局部子模块更新，但需要整体推送的情况，在提交代码时约定注释的前缀增加特殊标记如：push_allxxx)开头,如是则将每个子模块编译后结果推送到docker镜像仓库，结束脚本执行。如不需要整体推送则执行s3-2。

s3-2:执行gitshow命令，使用预定义变量ci_commit_sha(本次提交的版本号)，也可结合命令参数--name-status等，获得本次提交所影响的所有代码的文件路径，然后从中依次判断是否包含我们在第一步设置的子模块路径变量，如包含普通模块，则将该模块添加到待推送推送模块列表中，如包含公共模块则将其依赖的所有子模块添加到待推送推送模块列表中，然后将待推送模块列表去重，最后按照此列表依次将其中子模块的编译结果推送到docker镜像仓库。

以上所述仅为本发明较佳实例而已，本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。