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 <mark.ea...@gmail.com <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 <michae...@gmail.com 
>> <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 <mark.ea...@gmail.com 
>>>> <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 <michae...@gmail.com 
>>>>> <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 <michae...@gmail.com> 
>>>>>>> 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 <michae...@gmail.com> 
>>>>>>>>> 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 jenkinsci-use...@googlegroups.com.
>>>>>>>>>> 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 jenkinsci-use...@googlegroups.com.
>>>>>>>> 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 jenkinsci-use...@googlegroups.com <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 jenkinsci-use...@googlegroups.com <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 jenkinsci-use...@googlegroups.com <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 jenkinsci-use...@googlegroups.com <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 jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to