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

Provide a way to reset build number to 1 within Jenkinsfile for a Multibranch Pipeline

      Currently I am using the incremented build number provided by Jenkins for the release version of our iOS and Android app. Product/dev drive the release numbers. Once the feature branch is merged into master, a build is automatically kicked off and if the release number is incremented, I want to reset the build number back to 1. For example if 5.0.1 (5) is the current market release and dev merges a feature branch into master with a greater release number, like 5.0.2, I want to reset the build number back to 1 so that the app version is now 5.0.2 (1). My Jenkins is on a Linux server that uses a Mac OS X agent for building our iOS app. How do I reset the build number back to 1 after the build has automatically kicked off, checked out the source code, and checked to see if the build should be reset?

          [JENKINS-44757] Provide a way to reset build number to 1 within Jenkinsfile for a Multibranch Pipeline

          Derrik Ammons added a comment -

          It appears that this may be related to https://issues.jenkins-ci.org/browse/JENKINS-33046

          Derrik Ammons added a comment - It appears that this may be related to  https://issues.jenkins-ci.org/browse/JENKINS-33046

          Derrik Ammons added a comment -

          Since this appears to be a duplicate, I will close this.  I am happy to see that others have ran into the same issue.

          Derrik Ammons added a comment - Since this appears to be a duplicate, I will close this.  I am happy to see that others have ran into the same issue.

          victor borrull added a comment - - edited

          Hi derrikammons,

          In my opinion this is not a duplicated of JENKINS-33046

          I have a very similar request as you do. In my case the main issue is with Android release in Google Play. Our current version is 2.2.21 and build number is 331, the versionCode becomes 202213312 (20221 is the version, 331 is the build number, 2 is the architecture) but the maximum value allowed in Google Play is 2100000000, which means that we are either limited to 3 digits build number if we reach version 10.x.x or to 4 digits if we assume we will stick to single digit major version.

          Thus, as you do, we need to be able to reset the build number back to 1 when the major or minor version increases. Ideally, as you pointed out, this should be done from the JenkinsFile. I am not a Jenkins expert but I don't think that this is possible at the moment.

          victor borrull added a comment - - edited Hi derrikammons , In my opinion this is not a duplicated of JENKINS-33046 I have a very similar request as you do. In my case the main issue is with Android release in Google Play. Our current version is 2.2.21 and build number is 331, the versionCode becomes 202213312 (20221 is the version, 331 is the build number, 2 is the architecture) but the maximum value allowed in Google Play is 2100000000, which means that we are either limited to 3 digits build number if we reach version 10.x.x or to 4 digits if we assume we will stick to single digit major version. Thus, as you do, we need to be able to reset the build number back to 1 when the major or minor version increases. Ideally, as you pointed out, this should be done from the JenkinsFile. I am not a Jenkins expert but I don't think that this is possible at the moment.

          Mark Waite added a comment -

          What are the barriers that prevent you from encoding the release number in your source files and incrementing that build number when you release software? The Jenkins BUILD_ID really isn't connected to your release numbering technique, while your source code is strongly connected to your release numbering technique.

          Ant based builds can have the build.number file. Maven based builds encode the release in the pom file. I believe other build systems likewise have a way of giving the build software (ant, maven, cmake, make, ...) control of the release numbering scheme.

          Mark Waite added a comment - What are the barriers that prevent you from encoding the release number in your source files and incrementing that build number when you release software? The Jenkins BUILD_ID really isn't connected to your release numbering technique, while your source code is strongly connected to your release numbering technique. Ant based builds can have the build.number file. Maven based builds encode the release in the pom file. I believe other build systems likewise have a way of giving the build software (ant, maven, cmake, make, ...) control of the release numbering scheme.

          Hi markewaite, I believe that we actually have no barriers to do that. Actually it is probably better since it seems that resetting the Jenkins build number actually means deleting the builds using those numbers previously, thus losing the build history.

          We will implement some kind of auto increasing and resettable build number as part of the build process.

          Thanks

          victor borrull added a comment - Hi markewaite , I believe that we actually have no barriers to do that. Actually it is probably better since it seems that resetting the Jenkins build number actually means deleting the builds using those numbers previously, thus losing the build history. We will implement some kind of auto increasing and resettable build number as part of the build process. Thanks

          Derrik Ammons added a comment -

          Well, markewaite, I suppose you are correct that nothing prevents us from writing the build number ourselves, but I wanted to take advantage of Jenkins auto-incrementing build number feature so that developers don't have to worry about it.  Perhaps I don't quite understand completely the solution you are implying.  I would like for the developers to worry about coding features and fixing bugs, while the build server worries about building and releasing.  I wanted to put the logic in the jenkinsfile pipeline script so that whenever there is a commit the build kicks off and the build number is incremented automatically.  This works fine, but if release version is incremented in the master branch, then I wanted the build number to go back to 1.  The problem is that there are previous builds in the pipeline that prevent it to go back to 1.  Since several developers are merging branches, it's possible that they would make a mistake in setting the build number. Keep in mind the master branch was being built in a Multibranch Pipeline project.  Currently my solution was to remove the master branch build from the Multibranch pipeline project and create a single pipeline project to build the master branch.  Of course this is manual and not fully automated.  I have to create a pipeline project for each release, for example, 5.0.1 (3), 5.0.2 (6), and now we are at 5.3.2 (3) for iOS and likewise for Android, 5.2.0.11.  I had to pull out the master branch builds from the Android Multibranch pipeline project too.  The Mulibranch Pipeline project works perfectly for all the feature branch builds and defect branch builds, but not our release candidate builds.  Our feature branch builds never get their build number reset back to 1.  We just close them and delete them after they are merged into master.  I hope this makes sense.

          Derrik Ammons added a comment - Well, markewaite , I suppose you are correct that nothing prevents us from writing the build number ourselves, but I wanted to take advantage of Jenkins auto-incrementing build number feature so that developers don't have to worry about it.  Perhaps I don't quite understand completely the solution you are implying.  I would like for the developers to worry about coding features and fixing bugs, while the build server worries about building and releasing.  I wanted to put the logic in the jenkinsfile pipeline script so that whenever there is a commit the build kicks off and the build number is incremented automatically.  This works fine, but if release version is incremented in the master branch, then I wanted the build number to go back to 1.  The problem is that there are previous builds in the pipeline that prevent it to go back to 1.  Since several developers are merging branches, it's possible that they would make a mistake in setting the build number. Keep in mind the master branch was being built in a Multibranch Pipeline project.  Currently my solution was to remove the master branch build from the Multibranch pipeline project and create a single pipeline project to build the master branch.  Of course this is manual and not fully automated.  I have to create a pipeline project for each release, for example, 5.0.1 (3), 5.0.2 (6), and now we are at 5.3.2 (3) for iOS and likewise for Android, 5.2.0.11.  I had to pull out the master branch builds from the Android Multibranch pipeline project too.  The Mulibranch Pipeline project works perfectly for all the feature branch builds and defect branch builds, but not our release candidate builds.  Our feature branch builds never get their build number reset back to 1.  We just close them and delete them after they are merged into master.  I hope this makes sense.

          Mark Waite added a comment -

          derrikammons I think there is a key phrase in your reply which highlights the challenge

          ... if release version is incremented in the master branch, then I wanted the build number to go back to 1.

          That is more logic than the Jenkins build number is designed to support. The Jenkins build number is an increasing counter of builds that were launched.

          I think you want a release version number with more intelligence than the simple counter that is the Jenkins build number.

          There are probably ways to map the simple counter into a release version number, but I think it will be a continual struggle mapping the simple counter to your release version number semantics. I think that the intelligence of the release number will be easier for you to manage elsewhere, rather than trying to derive that intelligence from a simple counter.

          Mark Waite added a comment - derrikammons I think there is a key phrase in your reply which highlights the challenge ... if release version is incremented in the master branch, then I wanted the build number to go back to 1. That is more logic than the Jenkins build number is designed to support. The Jenkins build number is an increasing counter of builds that were launched. I think you want a release version number with more intelligence than the simple counter that is the Jenkins build number. There are probably ways to map the simple counter into a release version number, but I think it will be a continual struggle mapping the simple counter to your release version number semantics. I think that the intelligence of the release number will be easier for you to manage elsewhere, rather than trying to derive that intelligence from a simple counter.

            Unassigned Unassigned
            derrikammons Derrik Ammons
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: