There are many approaches to this problem, and I am not sure what your setup or requirements are, but here is some information that may be helpful.
* It is important to understand that any jenkins build has two ids - the actual immutable build_id - which is always consecutive for a job and specific to that job alone, and the build display name which is what you see in the UI. You can set the build display name to anything you want from within your job. By default it is # (pound symbol) followed by build_id. * You are usually better off having one build server with many slaves than parallel build servers that are independent of each other. This way as long as you are building the same job, it does not matter what slave you are building on, your build ids will be consecutive and unique. * If you do need multiple jobs on same master (even if builds are performed on any slave), you can write some code that will issue numbers from same pool. You can back that pool by anything, the simplest thing being writing a file to disk on master. I have implemented this many times via writing my own plugin, but these days it is far easier to do this via a pipelines shared library (if you are using pipelines, and you should). The simplest thing to do is to have a function that takes some id, and for that id it issues you next number by incrementing a synchronized counter somewhere. Of course this will still keep you on a single Jenkins master... * If you want to do this across multiple masters as you indicated (and I would strongly urge you to reconsider) - you can use the above with some sort of a shared storage resource that either supports atomic changes or locking - for example you can use a shared MySQL DB. You just have a table you lock and increment a counter in while locked (there are many other approaches too) * If you do not care for keeping a shared counter somewhere and do not mind longer build ids, a cheap and easy way to go is to assign each jenkins server an id number, then use a build name consisting of timestamp followed by server id, followed by whatever you want to guarantee it is unique within a single server. Your build ids will be long, but will always be in a sequential order - even if not consecutive. * All that said, I would also reconsider overall value of consecutive build numbers - in the end you probably only care about what branch it was done from and which commit it was done from. If you use a SCM that provides you with a sequential commit id (SVN is awesome for this) - just use the commit id as your build indicator. If you are using git or any other non-sequential commit SCM - you can just include the hash of the SCM on build and to get sequence, you can cheat a little by also counting commits in the log. Last bit is not exactly great as git allows you to rewrite your commit history, but if you can lock it down, it is reasonably functional indicator. Good luck, -M On Monday, September 19, 2016 at 12:54:15 PM UTC-7, Robert Kruck wrote: > > Is it possible to preserve the integrity of build numbers (NO DUPLICATES > and build numbers in order) while building in multiple Jenkins build > servers? > > If this capability exists in Jenkins, what Jenkins plugins are required, > and what versions of Jenkins itself, and of the required Jenkins plugins, > are needed? > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/84b32adc-04d5-417f-b0a6-01469c13ed5f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
