Curious to know what's the maximum number a Jenkins build number (BUILD_NUMBER) can get? I tried to find online but couldn't find this info.
Is it infinite or has some limit (being INT or INT64 or some other type)?
PS:
I'm NOT looking for how to reset it back to #1 or #N using the following plugin or set it value to a given name (using Set build name plugin).
https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
To find it's limit, using Next Build Number plugin - when I set the build to "65,535", it still worked in getting me 65536 successfully and I kept increasing this value to 999999999 (9 times), and it still worked i.e. the next build ran which was 1000000000 and reaped a valid Jenkins build# for few other runs/builds.
When I tried to set the next build number as: 9999999999 (10 times), Jenkins plugin barfed with an error mesg (which shows the next build number I set was not an INTEGER i.e. not in the range):
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)
Found Jenkins BUILD_NUMBER is a SIGNED Integer data type and INT signed limits are:
int 2 or 4 bytes -32,768 to 32,767 or -2,147,483,648 to 2,147,483,647
Thus, the last value that a Jenkins job can be set or built is: 2147483647 (4 bytes here). Setting anything above this number will generate the expected INT limit error.
Noticed the following issue as well, with SET NEXT BUILD NUMBER plugin:
If I set the next build number between -2147483648 or 2147483647 (positive), this plugin it works in both cases i.e. giving Negative or a positive Number and setting it doesn't error out. BUT, if you have already reached at build# 2147483647 (under Job history), then even setting the build# to 1 did NOT generate the next build as 1 or 2 . or 3 and so on.
As the BUILD_NUMBER is SIGNED (-N to +N in the above range) and for ex: setting -22 works for setting the next build# using the plugin, it didn't give me build# -21 or build# 21 in my case.
What's happening is, while providing a negative/lower value than the last/previous build# then this plugin is taking that value within the limit BUT not actually doing anything / giving me the expected BUILD#. When I'm clicking on Build Now / every time you hit Build Now and if you click on "Set Next Build Number" to check the value, I noticed that the number listed in the box was auto-decrementing by the number of times I hit "Build Now" (this happens only when you have reached the limit) and negative/lower value has no effect for the next build number (as per the plugin docs).
I tested this by creating a new test_job (discarded old builds by retaining only 1 build):
clicked on Build Now, got Build# 1.
Set next build number to 100.
Clicked Build Now, got Build# 100, Clicked Build now, Got build# 101.
Set Build number to 11 this time.
Clicked Build Now, but instead of giving me build# 12, Jenkins gave me build# 102 (PS: that's the intended behavior by this plugin as per it's documentation as setting next build number to a lower number N will not do anything).
Related
My Jenkins Version: 2.303.1
Stage View show 10 rows(build results) now.
Jenkins Stage View
Setting the discarding limit according to Melkjot will only increase the number of runs that are stored, it doesn't change the number ob entries shown in the stage view. However, there is a hardwired parameter mentioned in the plugins documentation at https://plugins.jenkins.io/pipeline-stage-view/
com.cloudbees.workflow.rest.external.JobExt.maxRunsPerJob (default: 10)
Open job configuration, under General tab check Discard old builds. Enter the number of builds you want to keep into Max # of builds to keep field.
Jenkins: Batch command returns negative value when we expect 0.
Jenkins Version - 2.249.1
After executing windows batch command - google test for the c++. All the tests were passed with few disabled tests. We are expecting a value 0, but received negative value. (-1073741819 ).
enter image description here
-1073741819
What is the issue here? Why are we getting a negative value?
This is leading to build failure.
Working with Gated/CI build definition (vNext) in TFS2017, the revision number is not increased correctly. Each build has the same Rev number even the changes are checked-in properly.
I get the revision number from $Env:BUILD_BUILDNUMBER via powershell at the beginning of the build process and it always returns the same number.
Make sure you are using the $(Rev:.r) token in the Build number format setting.
Build number format:
Use $(Rev:.r) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
If you want to show prefix zeros in the number, you can add additional
'r' characters. For example, specify $(rev:.rr) if you want the Rev
number to begin with 01, 02, and so on.
Also make sure the build number was not updated with the permanent number or string. (There is a possibility that used a script to customize your build process that updated the build number)
UPDATE1:
Please note that if the Major build number is changed in Build number format, then the revision number will not be changed. The Revision number only incremented when the Major part is not changed.
BTW, the token $(rev:.rr) should be used such as a variable, so the build number format should be something like : Test DEV CI_Rev.$(rev:.rr) in your scenario.
UPDATE2:
In your scenario you updated the build number with the assembly info every time. So, if the assembly info is different every time, then the revision number will no be changed, that's the expected behavior.
I just archieved my first app, but in the version number it get (1) after, even though the version number is changed every time I archieve? Is it the build number? Should I leave that blank?
The 1 in parentheses is the build number
Edit: Please see my own answer
With the xUnit-plugin in Jenkins I have configured Post-build Actions > Publish xUnit test result report > Failed Tests to set the Build Status as red, with a treshold of 1 (set in the Total field). The other fields are left empty.
But although having a test that fails, the status ball stays green. Worth mentioning is that the xUnit-plugin detects the failure. It is listed under Latest Test Result and also in the Test Result Trend graph.
Along with the configuration form the is a description stating: "..A build is considered as unstable or failure if the new or total number of failed tests exceeds the specified thresholds.". But seems strange, 1 will never exceed 1. Are you not allowed to set it as failure for a single failed test case? I can not recall seeing this before.
Ok, sometimes ones brain certainly malfunctions.
1 may not exceed 1 but it exceeds 0 for sure. I think I need to go on vacation.