Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43867

Jenkins build number set to lower number than current build number

    XMLWordPrintable

Details

    Description

      So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configure it to lower values I have to delete all the builds and then reset to the lower build number I wish. Which, almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like (1000 is build number and wish to change it to 500(not used for that job) )this they have to lose the build data of previous ones which are not a good thing for any organization.

      Attachments

        Activity

          karthik546 karthik paidi created issue -

          So what exactly is the bug here?

          The fact that Jenkins doesn't allow you to reuse build numbers?  Can you show me where such a use case would be valid or helpful?  How is deleting builds like creating a new job?

          Imagine for a second that you have a job with 10 builds (#1 through #10).  Let's say that you were allowed to change nextBuildNumber from 11 to 5.  What will happen when you run the job?  Will you have two builds #5?  Perhaps Jenkins is supposed to invent a #5.1 (5.2, 5.3 and so on) concept just for this?  Or do you expect the old build to be blindly overwritten by the new one?  Under what circumstances is build history overwriting helpful?  Are you comfortable with having a build #5 that is newer than build #10?

          I'm mostly asking all these questions out of curiosity.  The Next Build Number plugin (that's how you tagged this ticket), has nothing to do with what you're asking - that functionality is part of Jenkins core.  The plugin merely asks Jenkins to change the next build number, and Jenkins core decides what values are acceptable.

           

           

           

          akom Alexander Komarov added a comment - So what exactly is the bug here? The fact that Jenkins doesn't allow you to reuse build numbers?  Can you show me where such a use case would be valid or helpful?  How is deleting builds like creating a new job? Imagine for a second that you have a job with 10 builds (#1 through #10).  Let's say that you were allowed to change nextBuildNumber from 11 to 5.  What will happen when you run the job?  Will you have two builds #5?  Perhaps Jenkins is supposed to invent a #5.1 (5.2, 5.3 and so on) concept just for this?  Or do you expect the old build to be blindly overwritten by the new one?  Under what circumstances is build history overwriting helpful?  Are you comfortable with having a build #5 that is newer than build #10? I'm mostly asking all these questions out of curiosity.  The Next Build Number plugin (that's how you tagged this ticket), has nothing to do with what you're asking - that functionality is part of Jenkins core.  The plugin merely asks Jenkins to change the next build number, and Jenkins core decides what values are acceptable.      
          karthik546 karthik paidi made changes -
          Field Original Value New Value
          Description So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configured to lower values I have to delete all the builds and then reset to the lower build number I wish which is almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like this they have to lose the build data of previous ones which are not a good thing for any organization. So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configure it to lower values I have to delete all the builds and then reset to the lower build number I wish. Which is almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like this they have to lose the build data of previous ones which are not a good thing for any organization.
          karthik546 karthik paidi made changes -
          Description So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configure it to lower values I have to delete all the builds and then reset to the lower build number I wish. Which is almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like this they have to lose the build data of previous ones which are not a good thing for any organization. So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configure it to lower values I have to delete all the builds and then reset to the lower build number I wish. Which, almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like (1000 is build number and wish to change it to 500)this they have to lose the build data of previous ones which are not a good thing for any organization.
          karthik546 karthik paidi made changes -
          Description So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configure it to lower values I have to delete all the builds and then reset to the lower build number I wish. Which, almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like (1000 is build number and wish to change it to 500)this they have to lose the build data of previous ones which are not a good thing for any organization. So when I want to change my build number to some other number which is a higher value than current Jenkins is accepting in the set next build number, but if I want to set that to a lower value than the current, then Jenkins is not allowing that number. To configure it to lower values I have to delete all the builds and then reset to the lower build number I wish. Which, almost like creating a new job and starting a fresh build. It seems Jenkins only accepts build numbers in ascending order not in descending order. The issue that organizations have to face when they want to change the build number like (1000 is build number and wish to change it to 500(not used for that job) )this they have to lose the build data of previous ones which are not a good thing for any organization.

          Regarding your latest edits to the description:

          I think you are referring to having earlier builds discarded (by setting, for example, the build to keep only the last X builds).  So now you have, say, 10 builds with the most recent being #1000, so 991-1000.   Then you, for reasons that you still failed to explain, would like the next build to be #500.  Let's imagine that you get your wish.  What happens when the builds reach 991 again?

          Also, you may be failing to recognize the fact that among those organizations you referred to, many are using the build number to be the system of record for a version component of their software releases (or similar processes).  In such use cases they must never repeat.   For instance, in multiple organizations I've worked for, in a product release version "1.2.3.4.5", the 5 comes from $BUILD_NUMBER. 

          I've asked a number of questions in my previous comment, if you'd like to continue this thread then please address them.  If you don't, feel free to close this ticket.

           

          akom Alexander Komarov added a comment - Regarding your latest edits to the description: I think you are referring to having earlier builds discarded (by setting, for example, the build to keep only the last X builds).  So now you have, say, 10 builds with the most recent being #1000, so 991-1000.   Then you, for reasons that you still failed to explain , would like the next build to be #500.  Let's imagine that you get your wish.  What happens when the builds reach 991 again? Also, you may be failing to recognize the fact that among those organizations you referred to, many are using the build number to be the system of record for a version component of their software releases (or similar processes).  In such use cases they must never repeat.   For instance, in multiple organizations I've worked for, in a product release version "1.2.3.4.5", the 5 comes from $BUILD_NUMBER.  I've asked a number of questions in my previous comment, if you'd like to continue this thread then please address them.  If you don't, feel free to close this ticket.  
          karthik546 karthik paidi made changes -
          Attachment Screen Shot 2017-04-26 at 2.45.38 PM.png [ 37456 ]
          karthik546 karthik paidi made changes -
          Attachment Screen Shot 2017-04-26 at 2.53.21 PM.png [ 37457 ]
          karthik546 karthik paidi added a comment -

          So, I have a series to identify a particular build belongs to some release of the product. the same job can be executed for any release in that case if I started a build with 8000 and then I decide to change to different release which starts from  99. To change the build from 8000-99 I have to delete all those builds or delete the job and re-create a new one with 99 as next build number. In any case, I have to loose my build data right. If you can provide a mechanism to delete or skip the existing builds if reach to 8000 again at least I will have an option to check back old 8000 build, for at least a minute. If I set like only last 10 builds are enough for a branch or job then 8000 will be gone by the time 99 build reaches to 8000 (if this is available I don't even have to worry about going for lower number needs other builds to be deleted and can have 2 different releases stay for couple of days and then old release gets deleted at some point new one will continue. Well, in any case, i can manipulate build number if you feel working on this is not worthy enough please mark it completed.

          the following is screenshot shows 2 builds with same build number and 2 different graphs as well with the same build number.

          karthik546 karthik paidi added a comment - So, I have a series to identify a particular build belongs to some release of the product. the same job can be executed for any release in that case if I started a build with 8000 and then I decide to change to different release which starts from  99. To change the build from 8000-99 I have to delete all those builds or delete the job and re-create a new one with 99 as next build number. In any case, I have to loose my build data right. If you can provide a mechanism to delete or skip the existing builds if reach to 8000 again at least I will have an option to check back old 8000 build, for at least a minute. If I set like only last 10 builds are enough for a branch or job then 8000 will be gone by the time 99 build reaches to 8000 (if this is available I don't even have to worry about going for lower number needs other builds to be deleted and can have 2 different releases stay for couple of days and then old release gets deleted at some point new one will continue. Well, in any case, i can manipulate build number if you feel working on this is not worthy enough please mark it completed. the following is screenshot shows 2 builds with same build number and 2 different graphs as well with the same build number.
          karthik546 karthik paidi made changes -
          Attachment Screen Shot 2017-04-26 at 2.45.38 PM.png [ 37456 ]

          I think that you are misunderstanding the purpose of the build number, and are using it entirely incorrectly because you want one job's build number to mean different things on different days.  Neither I nor the Jenkins core team are likely to ever give you what you are asking for.  

          I see two options for you:

          1. If you want to continue to use $BUILD_NUMBER as your system-of-record, create distinct and separate jobs for each release type so that each job represents the next release version for that specific release type.  If there are a lot of release types (and thus many jobs), I'd recommend you look into bulk job generation with the Job DSL plugin.
          2. Stop using the $BUILD_NUMBER as your system-of-record.  Continue to use one job, but do not rely on $BUILD_NUMBER (thus you won't care whether the build numbers go up or down).  Use a separate system to keep track of your incremented versions per-release-type.  Use a database, a text file, whatever.

           

          akom Alexander Komarov added a comment - I think that you are misunderstanding the purpose of the build number, and are using it entirely incorrectly because you want one job's build number to mean different things on different days.  Neither I nor the Jenkins core team are likely to ever give you what you are asking for.   I see two options for you: If you want to continue to use $BUILD_NUMBER as your system-of-record, create distinct and separate jobs for each release type so that each job represents the next release version for that specific release type.  If there are a lot of release types (and thus many jobs), I'd recommend you look into bulk job generation with the Job DSL plugin. Stop using the $BUILD_NUMBER as your system-of-record.  Continue to use one job, but do not rely on $BUILD_NUMBER (thus you won't care whether the build numbers go up or down).  Use a separate system to keep track of your incremented versions per-release-type.  Use a database, a text file, whatever.  
          akom Alexander Komarov made changes -
          Resolution Not A Defect [ 7 ]
          Status Open [ 1 ] Closed [ 6 ]
          karthik546 karthik paidi made changes -
          Attachment Screen Shot 2017-04-26 at 2.53.21 PM.png [ 37457 ]

          People

            akom Alexander Komarov
            karthik546 karthik paidi
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: