allure插件打包的一些思考

问题一：

在使用部门项目的时候，因为它的版本【2.13.9】落后于开源的allure版本【2.21.0】太多，导致很多资源jar包都已经无法访问，依赖都下不下来了，所以也不用说能打出jar包来

在遇到这个问题的时候，我以为只要用最新版本的代码打个jar包就能解决问题，但是这个jar包和很多以前老的jar包有冲突（还有这个打的jar的依赖的jar包也有冲突😔），导致生成report的时候一直抛异常。

且我本机用的是java11（version 55）版本打的jar包，但是在打包机jenkins上运行的是java8（version 52），导致运行的时候一直抛JNI异常，版本有冲突。

搞了一个晚上，到凌晨2点都没什么思路（说明大晚上的改bug确实是不太可取的方案，这个时候人的大脑已经进入了一个极度疲惫状态😫，take a rest♨️）

睡了一觉，有了一些新想法，既然老版本已经不能用了，那就进行版本更新，升到最新版本

直接在jenkins的全局工具配置中去升级allure版本，让它也更新至最新，然后用最新版本的代码进行插件打包，这样既能解决依赖问题，也能解决jar包之间因为版本落后太多导致的冲突问题 😄

问题到此完美解决！ 🎉🎉🎉

问题二：

由于java基础太弱，在老的java中的一些可执行的二进制文件，通常会写入一些jar的依赖关系且是写死名字的，导致jar替换之后，很有可能会没有生效 。

如下图所示：

但在最新版中的allure可执行文件配置如下：

所以在以前的2.13.9版本的allure中如果jar包要进行替换，需要手动修改二进制文件中的classpath的路径情况，如果不想修改的话，需要保证打出来的jar名字一致。

问题三：

不知道如何对jenkins中的一些插件版本进行更新升级，这边也花了很多力气，

一般不会用自动更新的功能，都是本地下载好，然后重新定义指向情况。

 

问题四：

找相关的allure版本位置也找了一会儿，一般如果jenkins是部署在docker中的话，插件什么也会在容器里面，不要在容器外面找，一般都放在plugins和tools中。

问题五：

写代码的时候追求一个严谨，写代码和测试完全是两个思路，写代码的时候需要把所有的可能都考虑进去，保证项目的一个健壮性。

比如在写收集comic-auto项目里的一个case的执行次数和成功率的时候，在怎么统计的情况下，需要考虑到case 可能是全量执行，也可能是部分执行。

其他常用命令学习：

scp ./xxxx.jar root@ip_address:/root 将本地的一些文件上传到服务器上

docker cp ./xxxx.jar $container_name:~/workspace/lib 将物理机上的一些文件拷贝到容器里面 $container_name指的是容器名称，通常可以通过docker ps来查看到相关的容器名称

思考总结：

循此苦旅，以达天际。

冰冻三尺，非一日之寒。

技术的积累在于沉淀，不能一蹴而就，否则就像现在的自己，在坑里趴好一会儿，才能走出来，因为基础不牢固，所以总能遇到一些新问题。

最后分享一个在杀死一只知更鸟上看到觉得没有用但是在遇到问题需要激励自己的内容，【害怕的本身是最可怕的，除此之外，没什么是可怕的】，问题本身并不可怕，遇到问题就想退缩想放弃想当逃兵了，这才是最大的问题。