I suspect that was the issue... having the same git repository whose end 
point gets changed. Now you have the old master and the new master.

Though I still find it weird that it wanted to build twice.

On Thursday, 30 October 2014 08:10:05 UTC+2, Corneil du Plessis wrote:
>
> Did you wipe the workspaces after changing the git configuration?
>
> On 30 October 2014 00:05, Mark Waite <[email protected] <javascript:>> 
> wrote:
>
>> Were you using multiple repositories in the job?
>>
>> Had the job been through any special changes which might be relevant to 
>> understand why the code which asks the question "what needs to be built" to 
>> decide that more than one SHA1 needed to be built?
>>
>> Mark Waite
>>
>> On Wed, Oct 29, 2014 at 8:15 AM, michaelw <[email protected] 
>> <javascript:>> wrote:
>>
>>> 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] 
>>>> <javascript:>> 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] 
>>>>> <javascript:>> 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] <javascript:>.
>>>>>> 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] <javascript:>.
>>>>> 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] <javascript:>.
>>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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