Re: [controller-dev] Master broken

Robert Varga

I must have missed the reply... what does "almost never" mean? As far as I know the deployment to nexus is not atomic, which means that the versions automatically appended by nexus (timestamps?) may get mixed up and the same numbers may actually come from different builds. Debugging this sort of an 'almost never' situation could prove to a nightmare (and I have had my share of these :-/).

So can we make sure this never happens, please? :)


On 01/27/2015 03:15 AM, Luis Gomez wrote:

Hi Thanh, it looks like Andy already answered this will almost never be an issue because of the Nexus timestamps.

On Jan 26, 2015, at 3:02 PM, Thanh Ha <thanh.ha@...> wrote:

On 26 January 2015 at 16:48, Luis Gomez <ecelgp@...> wrote:
CC-ing Andy,

With Jenkins silos we could safely have merge and integration jobs pushing artifacts because these jobs (at least in the integration group Jenkins) are executed and queue in a single master Jenkins. Now my question is: How do we deal with a possible Nexus writing conflict in a JJB environment?

When it was just merge jobs, this feature was built in because for the merge type jobs we do not allow "concurrent" builds of the same job type.

However now that there's 2 different jobs that can publish artifacts we'd need to use a Jenkins plugin which adds a feature to lock a job from executing if another job in a list is currently running. There's a few options for this in Jenkins including the Build Blocker plugin or the Locks and Latches plugin.



Join to automatically receive all group messages.