On Wed, Feb 13, 2013 at 2:01 PM, Ross Youngblood
<[email protected]> wrote:
> Howdy sports fans.
> I'm working with Distributed builds, and I have a interesting problem.
> I discovered that using SSD drives was a big help in speeding up the builds
> of large files (my projects involve crunching large datasets for digital IC
> testers).
> Some of my build projects are 30Gb or larger. And I currently have only 2
> Jenkins build slaves with SSD drives (120Gb on one 60Gb on another), so SSD
> space for builds is at a premium.
>
> Without going into too much detail, I'd like these small projects that crunch
> a subset of the data in "trunk" to only check out portions of trunk.
> It looks like I'll have to build separate repositories with portions of the
> original trunk to do this, but it would have been nice to have a facility to
> checkout a list of files from the SVN repository as part of the project build
> instructions. This way Jenkins could maintain separate smaller workspaces
> that are independent of each other.
>
> The current method I use to manage this, is to have all the Jenkins slave
> projects use the same workspace directory, with the leading build doing the
> SVN checkout, and the subsequent builds just building in that workspace. On
> occasion there is resource contention with some common files which makes
> parallel builds on the slave less reliable.
>
> The copy files plug in might work for me, except that I would have to prepare
> a subdirectory with the files I want ahead of time. For that effort, I could
> have the copy operate via a script as part of the build… so I don't see the
> copy files plug in as being of as much utility as just having SVN.
>
> What I'd like is a way to specify a region for the checkout. I know with the
> SVN repo browser on Tortoise SVN, I can just check out individual files. So
> there has to be a command for that. I suppose I could build a series of SVN
> commands in the bat script … or probably build my own plug in. Any
> resources for plug-in development? Or if there is a plug-in solution that
> could help.
>
> I just found the toggle to upgrade from my SVN1.4 to 1.7, so I can have
> :external support, I could partition my svn repo using that technique… but
> it's a pain. I don't like the idea of forcing the SVN tree structure to be
> shaped by the number of execute engine parallel jobs.
As long as your code and data components have a structure with
directories for the parts you want to assemble together you should be
able to use a top level project with externals to pull any components
at any revisions you want into a working copy tree. They don't even
need to be from the same repositories.
--
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.
