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

Next Build Number plugin doesn't work for Workflow or Multi-branch Workflow jobs

    XMLWordPrintable

Details

    • Improvement
    • Status: Reopened (View Workflow)
    • Minor
    • Resolution: Unresolved
    • Jenkins ver. 1.644
      Workflow/Pipeline Plugins: 1.12
      Next Build Number Plugin: 1.3

    Description

      The Set Next Build Number menu link does not show up for Workflow or Multi-branch Workflow/Pipeline projects. See attached images of link present on a freestyle project, but missing on the workflow project, and on the multibranch workflow child/branch projects.

      Attachments

        Issue Links

          Activity

            Any obvious errors in the logs? (either on startup, during job creation, or while displaying the page) I currently don't have Workflow installed in any of my instances and may not have the opportunity for a bit.

            akom Alexander Komarov added a comment - Any obvious errors in the logs? (either on startup, during job creation, or while displaying the page) I currently don't have Workflow installed in any of my instances and may not have the opportunity for a bit.
            potatopankakes Jeff Burke added a comment -

            No errors on reboot. And, no messages in the logs when i visit a workflow project or a multi-branch workflow sub-project (the projects auto-created under the project folder).

            Btw, it also doesn't show up in dropdown menus of the projects either (but does show up for Freestyle project dropdown menus).

            potatopankakes Jeff Burke added a comment - No errors on reboot. And, no messages in the logs when i visit a workflow project or a multi-branch workflow sub-project (the projects auto-created under the project folder). Btw, it also doesn't show up in dropdown menus of the projects either (but does show up for Freestyle project dropdown menus).
            danielbeck Daniel Beck added a comment -

            These jobs aren't AbstractProjects, so
            https://github.com/jenkinsci/next-build-number-plugin/blob/master/src/main/java/org/jvnet/hudson/plugins/nextbuildnumber/NextBuildNumberAction.java#L94
            does not apply.

            TransientActionFactory<Job> or similar is probably the better choice.

            danielbeck Daniel Beck added a comment - These jobs aren't AbstractProjects, so https://github.com/jenkinsci/next-build-number-plugin/blob/master/src/main/java/org/jvnet/hudson/plugins/nextbuildnumber/NextBuildNumberAction.java#L94 does not apply. TransientActionFactory<Job> or similar is probably the better choice.

            Pull request with suggested change created: https://github.com/jenkinsci/next-build-number-plugin/pull/5
            I've tried in my local environment, seems to be working fine for both pipeline and freestyle projects.

            kad Alexander Kanevskiy added a comment - Pull request with suggested change created: https://github.com/jenkinsci/next-build-number-plugin/pull/5 I've tried in my local environment, seems to be working fine for both pipeline and freestyle projects.
            akom Alexander Komarov added a comment - - edited

            Version 1.4 includes changes by kad, thanks for that. Works for Pipeline jobs in my testing.

            The new version has been pushed and should show up shortly.

            akom Alexander Komarov added a comment - - edited Version 1.4 includes changes by kad , thanks for that. Works for Pipeline jobs in my testing. The new version has been pushed and should show up shortly.
            brydenoliver Bryden Oliver added a comment -

            Looks like it now works for Pipeline but not multibranch WorkFlow jobs.

            brydenoliver Bryden Oliver added a comment - Looks like it now works for Pipeline but not multibranch WorkFlow jobs.

            Does it make sense to set it for multibranch jobs? They are intended to be volatile (as branches come and go).

            akom Alexander Komarov added a comment - Does it make sense to set it for multibranch jobs? They are intended to be volatile (as branches come and go).
            brydenoliver Bryden Oliver added a comment -

            I know in our environment, we've completely ditched all other builds and use the Multibranch Workflow entirely.
            We keep a branch open for each currently supported release of our software, but would like to be able to assign a build number to those release branches as they are not transient.
            I completely agree for all the feature development branches, but for software shipped to customers and supported for several releases, a few branches would be very useful to be able to set a build number on.
            I'm aware of a number of other organisations in a similar boat as we had a chat at a recent meetup and this particular issue came up.

            brydenoliver Bryden Oliver added a comment - I know in our environment, we've completely ditched all other builds and use the Multibranch Workflow entirely. We keep a branch open for each currently supported release of our software, but would like to be able to assign a build number to those release branches as they are not transient. I completely agree for all the feature development branches, but for software shipped to customers and supported for several releases, a few branches would be very useful to be able to set a build number on. I'm aware of a number of other organisations in a similar boat as we had a chat at a recent meetup and this particular issue came up.

            akom Yep I couldn't agree more that it's absolutely unnecessary to set custom build numbers on feature/bugfix/hotfix jobs, but what about release branches? How should they be managed by design in Multibranch pipeline projects? Could you please suggest/shed some light on the intended workflow for them?

            The whole multibranch pipeline feature is super hot and we'd absolutely love to switch to it entirely, but still we'd like to keep the build number part of our workflow. Let me describe what it's like and why we want it. Assume our current master build number is N. We branch each release out of master and bump master build numbers to N + M, where M is a "window" that should be enough for this release branch lifetime. We do not build releases on each commit but every 4 hours, which makes it easy to make a fine estimate for M. This scheme makes build comparison straight-forward, by their build numbers. We can track where the branching has happened and determine where in commit history the particular build belongs (approx.) just by looking at its build number. Convenient because you can see if a patch was included into that particular build.

            Also, as brydenoliver has mentioned, build numbers might be visible to customers (which is true in our case as well, but we don't set them to something like '43p1'; we just bump the standard numerical build numbers in Jenkins), so I suppose many would like an opportunity to control them.

            Please, for the sake of never failing build, help.

            atikhono Anna Tikhonova added a comment - akom Yep I couldn't agree more that it's absolutely unnecessary to set custom build numbers on feature/bugfix/hotfix jobs, but what about release branches? How should they be managed by design in Multibranch pipeline projects? Could you please suggest/shed some light on the intended workflow for them? The whole multibranch pipeline feature is super hot and we'd absolutely love to switch to it entirely, but still we'd like to keep the build number part of our workflow. Let me describe what it's like and why we want it. Assume our current master build number is N. We branch each release out of master and bump master build numbers to N + M, where M is a "window" that should be enough for this release branch lifetime. We do not build releases on each commit but every 4 hours, which makes it easy to make a fine estimate for M. This scheme makes build comparison straight-forward, by their build numbers. We can track where the branching has happened and determine where in commit history the particular build belongs (approx.) just by looking at its build number. Convenient because you can see if a patch was included into that particular build. Also, as brydenoliver has mentioned, build numbers might be visible to customers (which is true in our case as well, but we don't set them to something like '43p1'; we just bump the standard numerical build numbers in Jenkins), so I suppose many would like an opportunity to control them. Please, for the sake of never failing build, help.

            This is not resolved, this fix only handles single pipeline builds, this fix does not handle multi-branch pipeline builds. Please re-open. Controlling build numbers is a requirement for our build process and this issue is causing us significant problems.

            nanoshot Nathan Frasier added a comment - This is not resolved, this fix only handles single pipeline builds, this fix does not handle multi-branch pipeline builds. Please re-open. Controlling build numbers is a requirement for our build process and this issue is causing us significant problems.

            Reopening since multibranch pipeline is not supported. Patches welcome, not sure when I'll get to this.

            akom Alexander Komarov added a comment - Reopening since multibranch pipeline is not supported. Patches welcome, not sure when I'll get to this.
            derrikammons Derrik Ammons added a comment - - edited

            I too need to be able to update our Release branch for both our iOS and Android apps.  I would like to reset the build back to 1 when a release is incremented in the plist for iOS or gradle file for Android.  There may be several builds in the previous release and after development merges their feature branches into the master branch along with an incremented release number, I want the build number to start from 1 again.  For example, if the previous release was 5.0.5 (24), and the source code has 5.1.0, the build starts back at 1 allowing the iOS app be 5.1.0 (1) and the Android app be 5.1.0.1.  I suppose that the 24 builds of the previous release will be removed.

            I will close my enhancement request that I filed, yesterday: https://issues.jenkins-ci.org/browse/JENKINS-44757 and watch this issue.

            Alexander, if this is not the same type of request, please let me know, and I can reopen my original request.

            derrikammons Derrik Ammons added a comment - - edited I too need to be able to update our Release branch for both our iOS and Android apps.  I would like to reset the build back to 1 when a release is incremented in the plist for iOS or gradle file for Android.  There may be several builds in the previous release and after development merges their feature branches into the master branch along with an incremented release number, I want the build number to start from 1 again.  For example, if the previous release was 5.0.5 (24), and the source code has 5.1.0, the build starts back at 1 allowing the iOS app be 5.1.0 (1) and the Android app be 5.1.0.1.  I suppose that the 24 builds of the previous release will be removed. I will close my enhancement request that I filed, yesterday: https://issues.jenkins-ci.org/browse/JENKINS-44757  and watch this issue. Alexander, if this is not the same type of request, please let me know, and I can reopen my original request.

            derrikammons: With regard to "resetting the build back to 1", what behavior are you expecting?   Jenkins does not permit setting build numbers lower than the highest existing build number (you can delete the old builds, however).  See JENKINS-43867  for a detailed discussion.

            akom Alexander Komarov added a comment - derrikammons : With regard to "resetting the build back to 1", what behavior are you expecting?   Jenkins does not permit setting build numbers lower than the highest existing build number (you can delete the old builds, however).  See JENKINS-43867   for a detailed discussion.
            derrikammons Derrik Ammons added a comment -

            Oops, sorry Alexander, I edited my original post that may explain my issue further.  I will look at 43867.

            derrikammons Derrik Ammons added a comment - Oops, sorry Alexander, I edited my original post that may explain my issue further.  I will look at 43867.

            I also interested in this.

            Use case: simple git-flow development cycle.

            There are stable branches: dev and master. When DEV is merged to master, master number will be lower than last night-build number. Customers are finding it strange.

            evilbeaver Andrei Ovsiankin added a comment - I also interested in this. Use case: simple git-flow development cycle. There are stable branches: dev and master. When DEV is merged to master, master number will be lower than last night-build number. Customers are finding it strange.

            People

              akom Alexander Komarov
              potatopankakes Jeff Burke
              Votes:
              8 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated: