
Hi Julian,
Here are the issues as I see it:
The best I can give you for a solution to this is to:
Hope this helps,
Chris

Hi Nick,
Those 2 errors are from the same issue. For some reason, git clone isn’t working, which means the scheduler can’t check for modifications…
What version of git are you using?
In order to debug this, the easiest thing to do is set logging to debug (change the first line in config/log4j.properties from INFO to DEBUG) and look in the cruise-server.log to see what command arguments are being passed into git clone. I usually try running that command on my own to see what errors are occuring.
If you want, you can email me your cruise-server.log file (with debug enabled) and I can try to debug it for you. My email address is cturner at thoughtworks.com
Chris

Hi there.
I just double checked the code and you are exactly right as to the nature of the problem. We are, indeed, wrapping the target field in quotes. I’m going to file this as a bug.
In the meantime, the work around is to use the exec task.
Chris

Will the source-code be checked out only when there is a modification? Or will forcing the build also check out the code?
So there are two things here… Cruise Server and Cruise Agent. For SVN, the server will never check-out the code (for Mercurial it does).
The agent will always check-out the source into a sandbox (Cruise Agent\pipelines) and run your nant script from there. It doesn’t matter if this is caused by a modification or forcing the build. They work the same.
Once the code is checked-out, how do I access it?
The <tasks> tag within the <job> tag are used for accessing your code. The current working directory is the root of your checked-out code, so you shouldn’t need to know where it is from a running your tests standpoint.
Is it within the C:\Program Files\Cruise Agent\ directory?
It will be checked out to C:\Program Files\Cruise Agent\pipelines\{pipelineName}
Are there any task variable I can use to access this path?
No. We just set the current working directory of all of the tasks (including the exec task) to be the root of the checked-out code.
Can I hard-code a path instead of the default location for checking-out?
There is currently no way to change where the agent checks out the code. We are looking into allowing this to be an option, but it’s not there yet.
After compiling is complete, I know I can save it in the Artifacts within Cruise. Is there a sample config or explanation on how to get this done?
Here is the help page dealing with publishing artifacts.
After I save the binaries in Artifacts within Cruise, how does the next stage access the binaries?
The answer to this is a little more involved. Look at my response here.
As I mentioned earlier, I would like to run NUnit to run unit tests. Can this be accomplished with a nant buildfile? Would the job configuration be:
<job name="RunUnitTests">
<tasks>
<nant buildfile="nant-file-for-running-unit-tests"
target="target-for-running-unit-tests" />
</tasks>
</job>
That looks right. The configuration reference for nant can be found here.
Hope this helps! If you have any other questions, just let us know.
Chris

Hey Pete,
Initially the sub tabs of the Job detail page all worked that way. We actually found that for the normal case, this was really annoying for users. They would click back and forth between Modifications and Failures tabs and expect the back button on their browser to send them (in your example) back to the stage activity page. Also, the requirement was raised to be able to stay in the same sub tab as we are looking thru a jobs history.
Good news, however. :) We just started playing a story to put a “link directly to this sub tab” link on each tab, so you can email from there. As a short-term workaround, however, all sub tabs (including ones created by you in the config file) have an anchor of #tab-(tabname) that will open that tab. For example, on one of our jobs we have a sub tab named “Emma”. The anchor is #tab-emma. Just add that to the end of a url you want to email somebody and that should send them to the correct tab.
Hope this helps,
Chris

Pete,
If you see this happening again, could you let us know? I just took a look at the code, and I’m not able to find how that could have happened…
Chris

Hey Pete,
Thanks. That one slipped passed us. It should have read, “It’ll be there for 1.1, promise.” ;-)
We’ll add this to the list of documentation fixes we need to take care of.
Chris

Hi Chris,
The issue here is that there is no way for us to XSD validate an XML partial. What we currently do is pull the information out of the XML snippit and load it into our domain object. Then we stream it out to XML (with XSD validation at this point). Any extra tags/attributes are ignored.
The ultimate solution that we are intending in order to solve this is to create wizards with fully verifiable input boxes (potentially leaving the XML snippets for power users)
Thanks,
Chris

The reason this is happening is due to RPM not knowing that you already have java 1.6 installed (since you installed it from source).
We’ve decided that the default use case would assume 1.6 being installed by rpm, mostly because we can be assured of where it’s installed. If this is not the case (as in your situation) we have no consistent way to know where JAVA_HOME should point to. The way to handle this is to ignore deps when installing and change the /etc/default/cruise-[server|agent] file to point JAVA_HOME to the correct folder. (Which, it sounds like, you figured out on your own).
Hope this helps,
Chris

Hi Joseph,
This is a really interesting idea… We’re definitely going to take a look at it. Right now, we’re thinking this would be more of a depends case than a material case, but with the same effect.
Currently depends is for triggering a pipeline when another stage completes successfully. This sounds like more of an external depends.
Chris