公司jenkins目前的用途是与git stash集成，在提交代码之前强制跑单元测试，以保障代码质量。再使用的3个月了，也出现了很多问题，现总结总结：
ut运行环境：nodejs+node modules+mongodb+mysql+redis
1、必须保障code运行环境及依赖关系、权限、硬盘空间等，不然的话跑挂就是家常便饭；
2、testing环境code更新速度远大于mysql表结构修改速度，所有要及时修改jenkins上的表结构，不然也会挂一大片；
3、为什么每台jenkins server只能同时跑一个build，因ut环境的所有项目基本都依赖一套db，且跑ut之前会清空数据，故只能同时跑一个，这与公司项目的特定环境有关；
4、既然每台只能跑一个，那么多项目，每次commit都需要跑ut，跑一次短则几分钟，长则二三十分钟，那是远远不能满足需求，需要搭建jenkins的master-slave集群来消化build task 队列，master只做任务调度，slave执行时间build任务，各套环境要保证一直，最好通过虚机模板批量clone slave；
5、如果执行的命令有很多那，那么按顺序执行，其中一条出错后这个任务就会终止，返回值为非0，且每次的终止位置可能不一致，这与命令接受到termina信号有关；
6、出现ut跑不过的时候的排错方法：
关于jenkins故障排除的步骤和小技巧：a、看一下jenkins上其他的build任务最近几个小时是否正常–>都失败的话–>问问同事mysql表结构是否有改变–>可以尝试重启jenkins–>还不行，，找admin；
b、看一下jenkins上其他的build任务最近几个小时是否正常–>个别失败的话–>重新trigger2次–>看一下jenkins报错原因–>在本地用同样的build命令跑对应分支–>看本地报错和jenkins报错是否一致，报错一致说明代码有问题；
c、超过30分钟的build任务可以手工结束；
d、jenkins环境一般不会改变，除非npm install安装包，还有其他问题直接喊出来吧；
e、重启jenkins。
7、jenkins每次build都是去git checkout -f commit-num，可以在本地拿对应commit跑跑ut来troubleshooting；
8、多trigger几次吧
9、所有ut跑完后，通知stash的过程有时候可能会很长时间，jenkins的notify stash的这个插件没有timeout设置，时间太长就kill掉重新trigger吧。
参考：
#13404608
版权声明：本文为博主原创文章，未经博主允许不得转载。
学习不是人生的全部，但学习都征服不了，那我还能做什么?
