Jenkins的构建编号和一个有趣的bug

什么是构建编号

jenkins每个job的每一次构建都有一个属于自己独立的构建编号，每一次的构建结果（成功或失败）所使用的编号都是不相同的。

正确的构建编号：每个job的每次构建结果使用不相同的构建编号

错误的构建编号：多个job的每次构建结果使用相同的构建编号

 

多个job相同的构建编号引起的bug

举例说明：

比如有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才可以被执行。

本次构建编号=上次编号+1

引发上面的bug 原因是多个job使用相同的构建编号。

那么我们是如何发现上面的计算公式的呢？

答案：从jenkins的运行日志中

打开 系统管理 – System Log（系统日志从java.util.logging捕获Jenkins相关的日志信息。） - 所有系统日志

用户的每一次操作，都有记录，可以从日志中发现上述公式

造成多个job构建编号相同的原因

上面的bug是否是jenkins自己引起的呢？

答案：否

打开jenkins的系统设置：

管理员身份登录 - 系统管理 - 系统设置 - 主目录 - 高级

 

jenkins的默认设置中，有一个主目录（workspace），并为每一个job和每一次的构建结果都提供了独立的目录

我原本是想修改默认的workspace（主目录），但错误地删除了jenkins为每一个job提供的独立目录（把工作空间根目录和构建记录根目录改成了固定值）

注意：主目录(workspace工作空间)是针对全局设置的，对于任何一个job还可以自定义工作空间，在后面的文章中，我会进行介绍。

每一次构建都产生了什么？

在jenkins中，每一次的构建记录都会被保留起来。

保存位置：默认保存在workspace/job name /构建编号/

每一次构建，都会创建一个以构建编号命令的文件夹

举例说明构建记录产生的文件

• log：保存着此次构建在Console中输出的日志
• build.xml：构建的信息，包括构建参数，构建结果，启动的用户名，启动时间戳
• changelog.xml：修改日志

所有job的根目录

单个Job的根目录

单个job的所有构建日志

单个job的单次构建记录