On Thu, Dec 5, 2013 at 8:09 AM, JR Cary <[email protected]> wrote: > > But let me try to explain in more detail. I have a job with a > main svn repo, several svn repos that are brought in as svn > externals and one that is a git checkout. These must all be > brought together for a build. > > main_repo (svn) > > svn_repo1 svn_repo2 git_repo > > At SCM upate, main_repo is updated, and this automatically > updates svn_repo1 and svn_repo2, as they are svn externals. On > the master each of those has an svn revision number. Then, > Jenkins seems smart enough that when it goes to the slaves, it > updates main_repo, svn_repo1, and svn_repo2 to the revision it > found on the master.
I don't think that is actually guaranteed, even for the top level: https://issues.jenkins-ci.org/browse/JENKINS-16753 Also, how does this job trigger if the git_repo changes? > However, git_repo is not updated on the master, as it is not > (cannot be) an svn external. The (poor) solution now is to have > our build script start with updating the git_repo (cd git_repo; > git pull). But this could potentially have git_repo on the > separate slaves in different states, if someone commits before > one slave is updated and after another. One option would be to use the build flow plugin where one job polls the repository and starts the flow job, then the build flow job starts all of the child jobs, passing parameters for the revision numbers. Not sure even this will work for the svn externals unless they are pointing to tags or peg revisions. -- Les Mikesell [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
