Chris Withers kirjoitti 1.7.2012 kello 23.40:

> On 01/07/2012 20:04, Jon Schewe wrote:
>> 
>>    http://jenkins.simplistix.co.__uk/job/testfixtures-buildout/
>>    <http://jenkins.simplistix.co.uk/job/testfixtures-buildout/>
>> 
>> Why not just create a git repo with submodules for all of the other
>> repositories and then point Jenkins at that?
> 
> That seems like working around a problem with the git plugin rather than the 
> "right" thing to do.


Your choices are (in no particular order):

A) Use git submodules

B) Use git subtrees

C) Use repo

D) Implement the "right" thing

E) Use something else than Jenkins


If we talk about A:

> Where would I put that repo? How would I stop people confusing it with 
> something useful?

Entirely up to you. The parent repo does provide a useful function: It ties 
together certain revisions of the submodules you want to include into a build 
and provides a versioned history of those revisions.

> More importantly, would changes pushed to any of the submodules cause that 
> repo to issue a request-to-build to the Jenkins server?
> (which is ultimately what I'm after here: I want to make sure that changes 
> pushed to the repos of both xlrd and xlwt cause the xlutils (which depends on 
> both packages) jobs to kick off)

Yes, it would. You would configure Jenkins with the address of the parent repo. 
Any change in the submodule repos does not take effect until the parent repo 
has been updated to refer to the new version of the submodule repo. When the 
parent repo is updated, Jenkins will trigger a new build.

About B: git subtrees is whispered as the challenger of git submodules, or git 
submodules done right. Unfortunately Jenkins does not support that, at least 
not yet.

About C: repo is the tool Android project uses to manage multiple git 
repositories (http://source.android.com/source/version-control.html). There is 
a Jenkins plugin for that: 
https://wiki.jenkins-ci.org/display/JENKINS/Repo+Plugin

About D: If you have a better idea how to do it right, you should implement a 
Jenkins plugin or enhance an existing plugin. You can also hire someone to do 
it for you.

About E: If none of the above works for you, maybe it is time to look 
elsewhere. Jenkins is not the only game in town. Just because it's popular 
doesn't mean it is the most suitable for all purposes. But it has the same 
money-back guarantee as all open-source software. :)

-- Sami

Reply via email to