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 wor
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 nee
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, mich
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 ha
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 de
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
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
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 jo
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
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 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 buck
11 matches
Mail list logo
