Multi-project pushes to Bitbucket not triggering all relevant Jenkins jobs

[Paul Hoadley]

Hello,

I'm using Jenkins 1.464.  I have a Bitbucket repository that contains several top-level directories, each of which represent a single Jenkins job.  I'm using the Git plugin and its "Included Regions" attribute to detect just those changes that are relevant to each job. [1]  The Bitbucket repo has a Service to hit the /git/notifyCommit?url=... on the Jenkins server.  Polling is checked for each project, but there's no schedule set. [2]  Hitting that URL from the shell gets a response listing all the expected jobs, so this certainly seems to be set up correctly.

The problem is that when I push changes that span multiple projects in the repo, only one of the projects is being built.  If it's the wrong project with respect to dependency order, the build breaks.  This seems to happen regularly, but I don't know whether it's deterministic.  It's certainly breaking the build often enough to be very annoying.

Has anyone seen this before?  I suppose a solution might be to set up separate Bitbucket "Jenkins Services", one for each project, but that's more typing than just hitting the one notifyCommit URL.

[1] As an aside, this seems like an impedance mismatch to me (special attributes, cloning the same repo multiple times for the separate jobs), and I am considering breaking the repo up into multiple single-project repos. This would have the advantage of solving the problem I describe above.

[2] All as described here: http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/

-- 

Paul.

[Sami Tikka]

Neither Jenkins or Git really support having multiple projects in one Git repository (at least not yet). The difficulties you are experiencing are a result of that.

I always thought you have to specify polling schedule if you check the polling box... but you can make the polling cycle very long, e.g. once a week.

-- Sami

Paul Hoadley <[hidden email]> kirjoitti 25.8.2012 kello 14.37:

> Hello,
>
> I'm using Jenkins 1.464.  I have a Bitbucket repository that contains several top-level directories, each of which represent a single Jenkins job.  I'm using the Git plugin and its "Included Regions" attribute to detect just those changes that are relevant to each job. [1]  The Bitbucket repo has a Service to hit the /git/notifyCommit?url=... on the Jenkins server.  Polling is checked for each project, but there's no schedule set. [2]  Hitting that URL from the shell gets a response listing all the expected jobs, so this certainly seems to be set up correctly.
>
> The problem is that when I push changes that span multiple projects in the repo, only one of the projects is being built.  If it's the wrong project with respect to dependency order, the build breaks.  This seems to happen regularly, but I don't know whether it's deterministic.  It's certainly breaking the build often enough to be very annoying.
>
> Has anyone seen this before?  I suppose a solution might be to set up separate Bitbucket "Jenkins Services", one for each project, but that's more typing than just hitting the one notifyCommit URL.
>
>
> [1] As an aside, this seems like an impedance mismatch to me (special attributes, cloning the same repo multiple times for the separate jobs), and I am considering breaking the repo up into multiple single-project repos. This would have the advantage of solving the problem I describe above.
>
> [2] All as described here: http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/
>
> --
> Paul.
>

[Richard Bywater-2]

Nope - just ticking the box and leaving the schedule blank works a
charm. No need to have that build for no reason :)

Richard.

On Sun, Aug 26, 2012 at 9:56 AM, Sami Tikka <[hidden email]> wrote:

> Neither Jenkins or Git really support having multiple projects in one Git repository (at least not yet). The difficulties you are experiencing are a result of that.
>
> I always thought you have to specify polling schedule if you check the polling box... but you can make the polling cycle very long, e.g. once a week.
>
> -- Sami
>
> Paul Hoadley <[hidden email]> kirjoitti 25.8.2012 kello 14.37:
>
>> Hello,
>>
>> I'm using Jenkins 1.464.  I have a Bitbucket repository that contains several top-level directories, each of which represent a single Jenkins job.  I'm using the Git plugin and its "Included Regions" attribute to detect just those changes that are relevant to each job. [1]  The Bitbucket repo has a Service to hit the /git/notifyCommit?url=... on the Jenkins server.  Polling is checked for each project, but there's no schedule set. [2]  Hitting that URL from the shell gets a response listing all the expected jobs, so this certainly seems to be set up correctly.
>>
>> The problem is that when I push changes that span multiple projects in the repo, only one of the projects is being built.  If it's the wrong project with respect to dependency order, the build breaks.  This seems to happen regularly, but I don't know whether it's deterministic.  It's certainly breaking the build often enough to be very annoying.
>>
>> Has anyone seen this before?  I suppose a solution might be to set up separate Bitbucket "Jenkins Services", one for each project, but that's more typing than just hitting the one notifyCommit URL.
>>
>>
>> [1] As an aside, this seems like an impedance mismatch to me (special attributes, cloning the same repo multiple times for the separate jobs), and I am considering breaking the repo up into multiple single-project repos. This would have the advantage of solving the problem I describe above.
>>
>> [2] All as described here: http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/
>>
>> --
>> Paul.
>>
>

[Paul Hoadley]

Hi,

On Sun, Aug 26, 2012 at 9:56 AM, Sami Tikka <[hidden email]> wrote:

>> I always thought you have to specify polling schedule if you check the polling box... but you can make the polling cycle very long, e.g. once a week.

On 26/08/2012, at 4:52 PM, Richard Bywater wrote:

> Nope - just ticking the box and leaving the schedule blank works a
> charm. No need to have that build for no reason :)

I can certainly confirm that it works... when it works.  But this does seem to be a bug:

>>> The problem is that when I push changes that span multiple projects in the repo, only one of the projects is being built.  If it's the wrong project with respect to dependency order, the build breaks.  This seems to happen regularly, but I don't know whether it's deterministic.  It's certainly breaking the build often enough to be very annoying.


In any case:

> On Sun, Aug 26, 2012 at 9:56 AM, Sami Tikka <[hidden email]> wrote:
>> Neither Jenkins or Git really support having multiple projects in one Git repository (at least not yet). The difficulties you are experiencing are a result of that.

I think I finally agree.  I've split the repo in four, and have re-organised Jenkins to build one-project-per-repo.  I think the upside here is much greater than the downside.  (Where the downside is that the projects were genuinely fairly closely coupled.  I would regularly push changesets for, say, some feature that spanned more than one of them.  Now those will have to be multiple commits across multiple repos.  But I can live with that.)


--
Paul.