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的单次构建记录
