|
Description:
|
When configuring a multi-configuration project in Jenkins using the SVN plugin, it appears there is a single, redundant copy of the source for the associated job checked out in the root workspace folder, on top of the copies that are checked out for each "axis".
For example, suppose you have a single axis configuration (called JENKINS_PLATFORM) with two possible values: win32 and x64. When you execute this job, you will end up with three copies of your source code. The exact folder structures depend on the job configuration, but generally they look something like this:
- .\MyCodeModule
- .\JENKINS_PLATFORM\win32\MyCodeModule
- .\JENKINS_PLATFORM\x64\MyCodeModule
(NOTE: .\ is the root workspace folder in these examples). At best, this causes un-necessary bloat and overhead on a build machine, checking out the source three times instead of two. At worse, if you happen to have a sub-folder in your source project that matches exactly one of the subfolder names generated by Jenkins you end up with Subversion checkout errors because a folder of the same name already exists. I exploited this particular problem quite easily with the following configuration:
- set job to use a custom workspace folder
- set the "Directory for sub-builds" to $JENKINS_PLATFORM
- set the Subversion checkout options with the "Local module directory" to "." (ie: the root workspace folder)
Doing so will first checkout your code module in the root folder, then subsequently it will attempt to create two subfolders, one called "win32" and one "x64" for each axis in the configuration. If, however, you have a folder called "win32" and / or "x64" in your code module (which we do), you'll end up with a folder clash.
Now, to me this seems to indicate one of several possible problems with the Subversion plugin and the matrix build project, including:
- The code checkout operation should only happen once, one for each of the threads that builds each axis (except, perhaps, in the case when the "Directory for sub-builds" option under the custom workspace configuration is set to "." - which forces all axis configurations to use the same workspace)
- The "Local module directory" field in the Subversion configuration options should be relative to the "current workspace folder", which should be a result of concatenating (a) the root workspace folder or the custom workspace directory (b) the directory for sub-builds
- All path properties, including the custom workspace directory, directory for sub-builds, and possibly the local SVN module directory, should respect the axis specific environment variables generated by the matrix runner to allow consistent parameterization of the configuration.
|
