目前所在的项目一直使用svn+maven+jenkins的管理方式,也基本能够满足项目的使用需要。
前面的博客说过,项目经过规范之后,产线的hotfix采用从tags下面拉取brunch分支的方式。由于项目的测试环节比较严格,规范之后还没有出现过产线需要紧急hotfix的情况,但是第一次拉取就出了问题。
场景复现
从tags拉取分支复制到brunch下的目录,在jenkins上搭建brunch分支的job,执行构建命令,然后去版本库查看版本。发现版本号没有自动+1生成3.2.82版本,原有的3.2.81版本被覆盖。当时我就一惊……
排错过程
首先检查了brunch分支上pom文件的版本号,发现版本号是3.2.82-snapshot,然后我就怀疑是版本号没写对。然后在jenkins上重新构建了一次。结果是再次生成3.2.81版本,pom文件没有变化。
然后检查jenkins的构建命令,没有任何问题。
然后检查jenkins分支的对应关系,没有任何问题。
然后求助搜索引擎,没有有价值的信息。
好像看不到出路了…..
笨办法,去查看jenkins构建命令的全部控制台输出,此时发现了一个奇怪的问题:
jenkins在构建的时候上传和下载的路径都指向了tags下版本快照,没有指向brunch修改的代码。机智的我立刻打开了brunch下面的pom文件,果然,maven在打包时生成的快照地址配置那里是写死的,指定了版本号和路径………
解决
修改pom文件的路径
<scm>
<connection>brunch地址</connection>
<developerConnection>brunch地址</developerConnection>
<url>brunch地址</url>
</scm>
再次执行构建命令,正常生成3.2.82版本,问题解决。
虽然是个小问题,但确实也是自己基础知识不牢靠,对maven的构建机制不够熟悉造成的,还是要多学点东西。

本文描述了一个关于使用svn+maven+jenkins进行项目管理时遇到的版本号覆盖问题及解决方案。作者通过排查发现,问题根源在于pom文件中指定的快照地址配置错误,最终通过修改pom文件中的路径配置解决了问题。
5898

被折叠的 条评论
为什么被折叠?



