Thanks...

So I think I've solved it...

The message : *Scheduling another build to catch up with XXX *crept into 
the build logs. 

This of course was scheduling a build (and doing it on _every_ build).

The branch to build is */master and this is what it has been for a while 
but at some point having this branch spec caused multiple builds to be 
registered.

I removed the * and made it remotes/origin/master and now I only get ONE 
build.

I am very glad I have solved the problem.

It would be nice to know why this *Scheduling another build to catch up 
with XXX *occurs (for what use case) because it only caused me major 
headaches.

On Tuesday, 28 October 2014 22:09:36 UTC+2, michaelw wrote:
>
> Wow... that would be great. I'm busy confirming it is unique to bitbucket. 
> I suspect it is.
>
> When I've narrowed it down I'll submit.
>
> Thanks
>
> On 28 October 2014 13:24, Mark Waite <[email protected]> wrote:
>
>> I'm not sure what else could be happening in that job. Could you submit a 
>> bug report, and attach the job definition for the failing job, and the 
>> build logs for the cases where multiple jobs are being executed to "catch 
>> up", yet the same SHA1 is used in each case during the "catch up"?
>>
>> Thanks,
>> Mark Waite
>>
>> On Tue, Oct 28, 2014 at 1:45 AM, michaelw <[email protected]> 
>> wrote:
>>
>>> Sha1's for all the builds are exactly the same. 
>>>
>>> On Tuesday, 21 October 2014 22:34:47 UTC+2, Mark Waite wrote:
>>>>
>>>> If polling is not configured, then you'll need to read the build log of 
>>>> each job that was run, and extract the differences between those jobs.
>>>>
>>>> Usually, "changes detected" means that the git plugin believes that the 
>>>> remote repository includes a branch which matches the "branches to build" 
>>>> in the job definition and which points to a SHA1 which has not yet been 
>>>> built.  It queues a build to run a job using that SHA1.
>>>>
>>>> Thanks,
>>>> Mark Waite
>>>>
>>>> On Tue, Oct 21, 2014 at 4:43 AM, michaelw <[email protected]> wrote:
>>>>
>>>>> There is nothing in my polling log and I have no polling configured.
>>>>>
>>>>> On Monday, 6 October 2014 18:26:21 UTC+2, Mark Waite wrote:
>>>>>>
>>>>>> If you've configured "branches to build" to use a wild card, and if 
>>>>>> there are changes on those branches compared to the last time they were 
>>>>>> built, then a bunch of builds will be queued for the changes on those 
>>>>>> branches.
>>>>>>
>>>>>> You might post your git polling log to show what changes it has 
>>>>>> detected, or the early part of the build log to show the state of the 
>>>>>> repository.
>>>>>>
>>>>>> Mark Waite
>>>>>>
>>>>>> On Mon, Oct 6, 2014 at 9:55 AM, michaelw <[email protected]> wrote:
>>>>>>
>>>>>>> Hi All...
>>>>>>>
>>>>>>> Whenever I kick off a build in jenkins it queues up a bunch of 
>>>>>>> builds claiming that it is doing so because changes are detected.
>>>>>>>
>>>>>>> I have disabled all polling etc.
>>>>>>>
>>>>>>> I did have the commit hook on but is also disabled.
>>>>>>>
>>>>>>> The only change is that we have moved our git repositories to bit 
>>>>>>> bucket... again no commit hook configured there.
>>>>>>>
>>>>>>> I have also monitored the logs during a build and I don't see 
>>>>>>> anything unusual...
>>>>>>>
>>>>>>> Please can someone help me trouble shoot this. Maybe I can dial up 
>>>>>>> the logging so that I can work out why jenkins is behaving like this?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- 
>>>>>>> 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 [email protected].
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Thanks!
>>>>>> Mark Waite
>>>>>>  
>>>>>  -- 
>>>>> 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 [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Mark Waite
>>>>  
>>>  -- 
>>> 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 [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Thanks!
>> Mark Waite
>>  
>> -- 
>> 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 [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> see my blog: 
> http://analysis102.blogspot.com
> http://audiblethoughts.blogspot.com
> http://outsideofficehours.blogspot.com
>  

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to