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).

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.

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.

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.

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.