关于jenkins的使用问题总结

公司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吧。

参考：

http://stackoverflow.com/questions/22814559/how-when-does-execute-shell-mark-a-build-as-failure-in-jenkins

http://stackoverflow.com/questions/13400445/jenkins-build-script-exits-after-google-test-execution/13404608#13404608