We have a utility that generates our build scripts when it is passed a directory path as an argument. The utility finds all the .sln files in the directory and its sub directories. Then it interrogates the sln files to find out what the project dependencies' are and then generates a build script. We use this utility in all of our CCNet projects. CCNet calls the utility and then the next CCNet task calls the resultant batch script.
The engineers wanted to use this utility for their daily local builds so I created a single batch file that calls the utility based on a known Build location that contains all our sln files and then calls the batch files that were just generated. Unfortunately, if one of the batch files failed it would exit out of the entire script with the exit code not allowing the engineer’s build to continue. Now this is expected behavior given that none of the generated scripts’ EXIT statements have the /B argument. So I added it.
Everything seemed to be fine when I ran my first tests. These were positive tests to make sure existing green CCNet projects would stay green. But then on my negative tests something unexpected came to light. My red build returned green. I wanted to validate this was the case so I removed the /B from the batch script and ran the test again. The build turned red.
I am not sure why this is the case. I looked through the CCNet doc but could not find the answer. I am not sure if this is a CCNet issue or a CMD.exe issue (CCNet uses this when shelling out to batch files.)
My solution was to add an argument to our script building utility. The utility, with the new argument present, will generate the scripts with the /B on the EXIT command. If the argument is not present then it does not include the /B. I then added the new argument to the batch script for the engineers and now we are all happy.
Well sort of. I still want to know why CCNet behaves this way. I created a thread on the ccnet-user google group discussion board. I’ll update you on any responses i get.
till next time…