Jenkins BUILD_NUMBER 限制 - 最大内部版本号
Jenkins BUILD_NUMBER limit - maximum build number
想知道 Jenkins 内部版本号 (BUILD_NUMBER) 可以获得的最大数量是多少?我试图在网上查找但找不到此信息。
它是无限的还是有一些限制(是 INT 或 INT64 或其他一些类型)?
PS:
我正在 NOT 寻找如何使用以下插件将其重置回 #1 或 #N 或将其值设置为给定名称(使用 Set build name 插件)。
https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
要找到它的限制,使用 Next Build Number 插件 - 当我将构建设置为“65,535”时,它仍然使我成功获得 65536,并且我不断增加这个值到 999999999(9 次),它仍然有效,即下一个构建 运行 是 1000000000 并且为其他几个 runs/builds.
获得了有效的 Jenkins 构建#
当我尝试将下一个内部版本号设置为:9999999999(10 次)时,Jenkins 插件出现错误消息(显示我设置的下一个内部版本号不是整数,即不在 运行ge):
A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened.
Stack trace
javax.servlet.ServletException: Build number must be an integer
at org.jvnet.hudson.plugins.nextbuildnumber.NextBuildNumberAction.doSubmit(NextBuildNumberAction.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
发现 Jenkins BUILD_NUMBER 是一个 SIGNED Integer 数据类型并且 INT 有符号限制是:
int 2 or 4 bytes -32,768 to 32,767 or -2,147,483,648 to 2,147,483,647
因此,可以设置或构建 Jenkins 作业的最后一个值是:2147483647(此处为 4 个字节)。设置高于此数字的任何值都会产生预期的 INT 限制错误。
使用 SET NEXT BUILD NUMBER 插件也注意到以下问题:
如果我将下一个内部版本号设置在 -2147483648 或 2147483647(正)之间,此插件在两种情况下都有效,即给出负数或正数并且设置它不会出错。但是,如果您已经到达 build# 2147483647(在 Job history 下),那么即使将 build# 设置为 1 也不会将下一个构建生成为 1 或 2 。或 3 等等。
因为 BUILD_NUMBER 是有符号的(上述范围内的 -N 到 +N),例如:设置 -22 用于设置下一个使用插件的构建#,在我的例子中,它没有给我 build# -21 或 build# 21 。
发生的事情是,虽然提供了一个 negative/lower 值而不是 last/previous build# 然后这个插件在限制范围内获取该值但实际上没有做任何事情/给我预期的 BUILD#。当我点击 Build Now / 每次你点击 Build Now 并且如果你点击“Set Next Build Number”来检查值,我注意到框中列出的数字是自动递减我点击"Build Now"的次数(这只发生当您达到限制时)并且 negative/lower 值对下一个内部版本号没有影响(根据插件文档)。
我通过创建一个新的 test_job 来测试它(通过仅保留 1 个构建来丢弃旧构建):
- 点击“立即构建”,获得构建#1。
- 将下一个内部版本号设置为 100。
- 点击立即构建,获得构建#100,点击立即构建,获得构建#101。
- 这次将内部版本号设置为 11。
- 点击立即构建,但 Jenkins 没有给我构建#12,而是给了我构建#102(PS:这是这个插件的预期行为它的文档是将下一个内部版本号设置为较低的数字 N 不会执行任何操作)。
想知道 Jenkins 内部版本号 (BUILD_NUMBER) 可以获得的最大数量是多少?我试图在网上查找但找不到此信息。
它是无限的还是有一些限制(是 INT 或 INT64 或其他一些类型)?
PS: 我正在 NOT 寻找如何使用以下插件将其重置回 #1 或 #N 或将其值设置为给定名称(使用 Set build name 插件)。 https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
要找到它的限制,使用 Next Build Number 插件 - 当我将构建设置为“65,535”时,它仍然使我成功获得 65536,并且我不断增加这个值到 999999999(9 次),它仍然有效,即下一个构建 运行 是 1000000000 并且为其他几个 runs/builds.
获得了有效的 Jenkins 构建#当我尝试将下一个内部版本号设置为:9999999999(10 次)时,Jenkins 插件出现错误消息(显示我设置的下一个内部版本号不是整数,即不在 运行ge):
A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened.
Stack trace
javax.servlet.ServletException: Build number must be an integer
at org.jvnet.hudson.plugins.nextbuildnumber.NextBuildNumberAction.doSubmit(NextBuildNumberAction.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
发现 Jenkins BUILD_NUMBER 是一个 SIGNED Integer 数据类型并且 INT 有符号限制是:
int 2 or 4 bytes -32,768 to 32,767 or -2,147,483,648 to 2,147,483,647
因此,可以设置或构建 Jenkins 作业的最后一个值是:2147483647(此处为 4 个字节)。设置高于此数字的任何值都会产生预期的 INT 限制错误。
使用 SET NEXT BUILD NUMBER 插件也注意到以下问题:
如果我将下一个内部版本号设置在 -2147483648 或 2147483647(正)之间,此插件在两种情况下都有效,即给出负数或正数并且设置它不会出错。但是,如果您已经到达 build# 2147483647(在 Job history 下),那么即使将 build# 设置为 1 也不会将下一个构建生成为 1 或 2 。或 3 等等。
因为 BUILD_NUMBER 是有符号的(上述范围内的 -N 到 +N),例如:设置 -22 用于设置下一个使用插件的构建#,在我的例子中,它没有给我 build# -21 或 build# 21 。
发生的事情是,虽然提供了一个 negative/lower 值而不是 last/previous build# 然后这个插件在限制范围内获取该值但实际上没有做任何事情/给我预期的 BUILD#。当我点击 Build Now / 每次你点击 Build Now 并且如果你点击“Set Next Build Number”来检查值,我注意到框中列出的数字是自动递减我点击"Build Now"的次数(这只发生当您达到限制时)并且 negative/lower 值对下一个内部版本号没有影响(根据插件文档)。
我通过创建一个新的 test_job 来测试它(通过仅保留 1 个构建来丢弃旧构建):
- 点击“立即构建”,获得构建#1。
- 将下一个内部版本号设置为 100。
- 点击立即构建,获得构建#100,点击立即构建,获得构建#101。
- 这次将内部版本号设置为 11。
- 点击立即构建,但 Jenkins 没有给我构建#12,而是给了我构建#102(PS:这是这个插件的预期行为它的文档是将下一个内部版本号设置为较低的数字 N 不会执行任何操作)。