Quick background. We have been using CruiseControl for continuous integration for several years now. We have found it to be painful in general to use and maintain, but much too valuable to give up on. I have looked at some of the other free tools available, but not found a compelling replacement. We currently have 25 projects running on our main CC server as well as a couple additional servers running a handful of projects.
We have been using IDEA for even longer and have always been pleased with the products from Jetbrains. Seeing that you were coming out with a continuous integration server got me very excited, especially since we've been having more problems with CC lately. I'm also beginning to evaluate Pulse from Zutubi.
I looked at the first few EAPs, but none of them seemed to be at the point where I would consider tackling them. 1075 finally looked good and I went ahead and spent some effort trying to configure it to do some of our builds.
I wasn't real happy having to put my CVS password in the config file. This is something we'd normally have checked in and I'm not checking in a file with my password in plaintext.
Since we were using CC with ant, we have ant targets already written that do most of what we want for testing. We usually modify these targets with CC tags (equivalent to -D on the ant command line or a in the build file itself) to modify the behavior of the specific build. These would include things such as database target, app server target, whether or not to fail on test failures, etc.
I have not been able to figure out how to modify the behavior using TeamServer in this way. There seems to be something similar in TS with the tag, but it looks to me like that is used for TS specific config, env or system config, at least according to the FAQ. In any case, I didn't get the behavior I expected when trying to change the database target. For example, I tried both:
but neither worked. From the ant command line, I would use:
% ant -Dtarget.db=sqlserver
So basically I was only able to get the builds to work with the default behavior.
I was able to create several agents and have them successfully connect to the server. These agents have different environments. Some have database systems on them. Some are Windows and some Linux. Some have 1.4 JDK, some 1.5, some both. JDKs from different vendors, also (Sun, BEA, IBM). In general, there are several qualitities to them that are both useful to know and are needed for choosing whether to build on them for certain builds (if we want to do a build that tests against WebSphere, we need to make sure the machine has WebSphere).
It appears that this is somewhat handled, but I was unable to find any kind of documentation on how to configure things on both the agent side and the server side to handle this. I assume on the server side, it is using the section, but I don't know how to communicate that an agent is on a machine with WebSphere and that a build needs WebSphere in order to run. I want to indicate that attribute explicitly in the agents file and have some check on the server side to only assign said build to agents with that attribute.
Anyway, back to doing the standard builds. First, I could not figure out how to use our own ant instance. We have a number of custom tasks defined for our build system, so it would be nice to use our preconfigured ant to do the build. Luckily, most of the had reasonable classpath definitions, so I was able to get our build working with the ant plugin supplied by the agent.
Then I started getting OutOfMemory errors when doing some of the builds. We have -Xmx boosted up to 1024m on our system. I was unable to figure out how to indicate that this parameter be passed to ant. I tried:
in build-server-config.xml to no apparent avail. So most of our builds simply fail when they run out of memory.
Some of the builds did go through, though. I should say some builds on certain servers, as it wasn't consistent between servers (we have 2 Linux and 1 Windows agent running). I had some trouble debugging the builds as the output is pretty considerable and having it all dumped out made it a bit tricky. But was able to figure it out eventually.
I still don't have a clean build for anything, though I'll probably add a few simpler builds that only do compilations just so I can see some green and get a better feel for the product. Once I have things running a little better, I can give a better evaluation and compare it to our existing CC system to give feedback on what is good/bad/missing from someone coming from that environment.
- I could not figure out how to pass java parameters to the ant builds on the agents.
- I could not figure out how to pass -D parameters to the ant builds on the agents.
- I could not figure out how to classify the agents and then specify attributes in the build configuration to target only those agents which qualified.
- I was not happy with having to include my CVS password in plaintext in the configuration file.
- The log output was quite voluminous and could benefit greatly from some way of collapsing it down to just the top level tasks with the ability to expand a given section to find details.
- I could not figure out how to use our own version of ant.
- I could not figure out how to use a JDK other than that used for the agent to do the ant builds.
I'm sure some of these are there already. If they are not, please indicate and I'll file Jira issues.
On a positive note, I really like what I see and am very excited by the possibilities. It looks like a great system, especially so early on in its lifetime. I can't wait to pull the plug on CruiseControl.