Question

I'm experimenting with a Jenkins setup to improve our CI strategy which currently consists of an Automated Build Studio script getting kicked off by a Windows task scheduler. The source code that I want to integrate is a .NET solution which I'm attempting to build via MSBuild.

As our SCM we use StarTeam (v. 10.4) and I'm currently experiencing issues when Jenkins attempts to check-out files to the workspace and compile the solution.

There are certain files (it appears to always be the same) which don't get checked-out by the Jenkins StarTeam plugin. Obviously, Since these files are missing I'm unable to use Jenkins for CI. I'm not experiencing this issue with our Automated Build Studio script: Here all files are checked out correctly.

From my point of view there's nothing special about the C# files which don't get checked out: They're in different projects, contain different type of data (some winforms, some interfaces), they're all part of the same view, appears to have been added to StarTeam in the same manner etc.

The StarTeam polling log in Jenkins doesn't reveal anything. I don't know if there is some kind of debug mode that I might be able to use in order to trace down the nature of the problem?

Perhaps I should add that currently Jenkins runs locally on my desktop pc (Win7) whilst I'm experimenting with a setup. I'm using a default location of c:\Program Files(x86)\Jenkins\Jobs\JOB_NAME\Workspace to integrate my solution.

I hope some of you guys might have an idea about what the issue is, as I would really like to have a better CI setup than what we currently have in place.

Was it helpful?

Solution

I managed to identify the problem: Apparently, one of the developers in our team sometimes manages to change the default location property of folders when adding them to StarTeam. So instead of checking in files with a location relative to the project root, we end up with an absolute path in our repository.

I was able to verify this by deleting the file in the original location (i.e. NOT in the Jenkins jobs folder) and then watch as the files reappeared in their original location during the Jenkins checkout. What really lead me to investigate this further was to try an checkout the files from StarTeam using a cmd-line utility to check the files into a different location. When this still didn't get all the files checked out I assumed that Jenkins was no longer to blame but instead something else was wrong.

The reason I hadn't noticed this before is partly due to my little experience with StarTeam and due to all of the developers in our team using the same mappings and paths in our development environment. Hence, the absolute path placed the file in the right location on all machines because the paths used were identical.

OTHER TIPS

Essentially the StarTeam SDK handles the checkout of the files when integrating with any external application. The 10.4 build of client you are running seems quite out of date so I would recommend upgrading the SDK build if not the entire client.

StarTeam has relatively good forward/backward compatability when it comes to client/SDK so you could in theory run a 2009/2009R2 SDK against your existing 2008 R2 client installation.

As far as the debugging mode within Jenkins, you can activate this in the command line by running the following syntax:

java -Drally.debug="true" -jar jenkins.war --httpPort=9000

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top