问题来源
流水线程序员遇到的问题,他们显示在前天执行的一次流水线构建产物和最近一次的构建产物不一致。
问题描述
熟悉 Devops 的各位都知道,普遍存在这种现象:本地执行测试打包正常的 jar 在线编译过程中,会出现各种问题 u。这一此属于比较值得重视的问题。
功能没有任何区别的两个 jar,但是打出来的包大小是一样的,用的同一条流水线,但是发现凭空少了很多的包。
使用容器内 maven 本地依赖和不适用容器内 maven 依赖打出的包的区别(两个区别就是编译下载是否使用自己的私服地址下包)
问题定位
确定不是代码问题后,我首先使用的是一种笨办法。
直接使用 beyond compare 比较两次包多出了那些内容。
确实向他们所说的那样,两次包差别很大,凭空多了 20m 的大小,关键的是都是一些公共文件。
一开始通过经验判断是公司内的私有包 jar 依赖的 pom 文件不一致,我首先是要查找这两个包。
因为直接从 jar 里看 jar 包无法判断那些包是行内的那些事公共的包。
因为公司使用的事 nexus 管理 java 依赖,所以找出所有的不一致 jar 包后,进一步分析。
这些包分为两类,一种事凭空多出来的依赖,一种是版本不一致,但是 jar 包名一致。那么重点分析第二种:
原因如下:
- pom 保存 nexus 依赖关系,如果有区别的话肯定会在 nexus 中查找
- 多出来的包普遍是公共包。(即中央仓库拿到的,不是公司自研的),而版本不一致的包就是公司自研的
可以判断出是该事业群配置管理错误操作导致的包问题。
下面就陷入一点困境,我下一步无法确定到底是哪一类包导致的问题,因为从仓库的引用中没有找到对应的 dependence 依赖;请教我的师傅,学到了一个命令。
mvn dependency:tree
查看 jar 包的间接依赖, 进一步判断是那个依赖版本的区别。
注意:使用流水线对应问题的 settings.xml,这样必须是这个项目组自己的私服地址。
谢天谢地,找到了。
这一次我已经可以从 pom 文件中找到版本的区别了。
接下来一个步骤就是给用户一个问题总结,验证。
我要通过管理员登录这个 nexus,然后搜索对应的仓库下的 pom 文件,发现对应的 jar 包目录下确实有 pom,下载后比较,验证了我的想法。
问题总结
所以我们总结,就是配置管理上传私有包,jar 和 pom 是分开上传的,导致 nexus 自己生成了一个 pom 文件(我们在对应的 release 仓库里默认配置的是不允许重复提交,原因属于公司业务特性。)导致 pom 上传不生效。
所以少了很多的 jar 包。
重新上传了 jar 和 pom 后,两次打包大小正常了。任务完成……
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于