Re: jenkins building when it shouldn't
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 > > 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 > > 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 >>> > 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 > 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 >>> 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 > 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 recei
Re: jenkins building when it shouldn't
Did you wipe the workspaces after changing the git configuration? On 30 October 2014 00:05, Mark Waite 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 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 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 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 >> 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 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
Re: jenkins building when it shouldn't
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 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 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 >>> 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 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 >>> 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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Thanks! >>> Mark Waite >>> >>> -- >>> You r
Re: jenkins building when it shouldn't
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 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 >> 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 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 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-users+unsubscr...@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-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > see my blog: > http://analysis102.blogspot.com > http://audiblethoughts.blogspot.com > http://outsideofficehours.blogspo
Re: jenkins building when it shouldn't
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 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 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 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 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-users+unsubscr...@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-users+unsubscr...@googlegroups.com. > 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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: jenkins building when it shouldn't
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 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 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 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-users+unsubscr...@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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: jenkins building when it shouldn't
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 > 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 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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: jenkins building when it shouldn't
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 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 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-users+unsubscr...@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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: jenkins building when it shouldn't
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 > 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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: jenkins building when it shouldn't
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 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-users+unsubscr...@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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
jenkins building when it shouldn't
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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
