On 12/5/13 10:41 AM, Les Mikesell wrote:
On Thu, Dec 5, 2013 at 8:09 AM, JR Cary <c...@txcorp.com> 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
Oh. In that case I am working to hard. I guess I just need to
work at a time when no one might commit.
Also, how does this job trigger if the git_repo changes?
These are all schedule builds, not triggered by 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.
I see. Thanks for the suggestions!
John Cary
--
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/groups/opt_out.