jenkins每个job的每一次构建都有一个属于自己独立的构建编号,每一次的构建结果(成功或失败)所使用的编号都是不相同的。
正确的构建编号:每个job的每次构建结果使用不相同的构建编号
错误的构建编号:多个job的每次构建结果使用相同的构建编号
举例说明:
比如有A,B,C三个job,使用相同的构建编号
当A构建时,将构建编号由1011提升至1012。
而此时要构建B,则必须连续点击二次,才会出现响应。
原因:B的初始编号为1011,它需要比当前的最大+1,才可以被构建。构建编号的递增 1011->1012->1013
而如果要构建C,则必须连续点击三次,才会出现响应。
原因:C的初始编号为1011,它需要比当前的最大+1,才可以被构建。1011->1012->1013->1014
如果多个job的构建编号是相同的(共享同一个),当产生一个新的最大构建编号时,其它job就会出现连续多次点击都未响应。
它直到点击N多次将自己的构建编号累加到比最大的编号+1,这个job才可以被执行。
引发上面的bug 原因是多个job使用相同的构建编号。
那么我们是如何发现上面的计算公式的呢?
答案:从jenkins的运行日志中
打开 系统管理 – System Log(系统日志从java.util.logging捕获Jenkins相关的日志信息。) - 所有系统日志
用户的每一次操作,都有记录,可以从日志中发现上述公式
上面的bug是否是jenkins自己引起的呢?
答案:否
打开jenkins的系统设置:
管理员身份登录 - 系统管理 - 系统设置 - 主目录 - 高级
jenkins的默认设置中,有一个主目录(workspace),并为每一个job和每一次的构建结果都提供了独立的目录
我原本是想修改默认的workspace(主目录),但错误地删除了jenkins为每一个job提供的独立目录(把工作空间根目录和构建记录根目录改成了固定值)
注意:主目录(workspace工作空间)是针对全局设置的,对于任何一个job还可以自定义工作空间,在后面的文章中,我会进行介绍。
在jenkins中,每一次的构建记录都会被保留起来。
保存位置:默认保存在workspace/job name /构建编号/
每一次构建,都会创建一个以构建编号命令的文件夹
举例说明构建记录产生的文件
所有job的根目录
DBA.png" border="0">
单个Job的根目录
单个job的所有构建日志
单个job的单次构建记录