Initial Impressions

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: and 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.

To summarize:

- 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.

--Tim

3 comments
Comment actions Permalink

Hello Tim,

Firstly, thanks a lot for your valuable feedback. It clearly shows
weak areas in the Albus and we'll surely address them in the release.
We've started working on Web-based administration interface and your
feedback will help us to make it more usable as well.

Tim McNerney wrote:

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.


We plan to support .cvspass file on the server, and this should solve
the problem. Please monitor http://www.jetbrains.net/jira/browse/TW-183


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 <param> 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:

<param name="system.target.db" value="sqlserver"/>

and

<param name="env.target.db" value="sqlserver"/>

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.


You used correct parameters, for -Dtarget.db you should use
system.target.db. Please make sure that you placed your custom tags under section (and not under ]]>). If
this won't work, please file a Jira bug with your configuration.


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 <requirements> 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.


I think we should have included this in the FAQ.

To specify, that your build requires websphere, you can write the
following in your build configuration on the server:

]]>

Albus will load the change without need to restart.

After that you can configure build agents to match this requirement by
adding the following line into buildAgent/bin/buildAgent.properties:

env.WEBSPHERE_HOME=/path/to/WebSphere

After that, build agent should be restarted.


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 <taskdefs> had reasonable classpath definitions, so I was able to get our build working with the ant plugin supplied by the agent.


If you setup ANT_HOME enviroment variable on build agent, it will be
used by our Ant runner. Only libraries will be used, not ant script.


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:

<param name="env.ANT_OPTS" value="-Xmx1024m"/>

in build-server-config.xml to no apparent avail. So most of our builds simply fail when they run out of memory.


You can pass arbitrary JVM settings to build runner by specifying the
following parameter in run-parameters section:

]]>

I updated FAQ regarding this option only yesterday, but it is
available in the current EAP.


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.

To summarize:

- I could not figure out how to pass java parameters to the ant builds on the agents.


Use jvmArgs run-parameter (see above).


- I could not figure out how to pass -D parameters to the ant builds on the agents.


Use param tag in ]]> section with system. prefix


- 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.


1. configure ]]> in build configuration on server, and
2. configure appropriate variable in buildAgent.properties file on
the build agent.


- I was not happy with having to include my CVS password in plaintext in the configuration file.


We will support .cvspass 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.


Currently, we use two modes for the build log: important messages
(with status at least WARNING) and all ones. Additionaly, we redesigned
build log to make it more readable (will be available in the next EAP
this week). If you'll need better organization of the log, feel free to
add Jira request.


- I could not figure out how to use our own version of ant.


Use ANT_HOME variable on the build agent machines.


- I could not figure out how to use a JDK other than that used for the agent to do the ant builds.


Use JAVA_HOME variable to point to appropriate JDK. It will be used
to start Ant. When a build is started, build agent logs a debug message
to console with path of java executable used.


I'm sure some of these are there already. If they are not, please indicate and I'll file Jira issues.


We're really appreciate your help and your feedback. I hope I
clarified things a bit, if not, please ask more :)


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.


Thanks for the warm words and for your feedback. We work hard to make
Albus useful and usable, though there are many glitches yet.

With kind regards,
KIR


--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

I think we should have included this in the FAQ.
To specify, that your build requires websphere, you
can write the
ollowing in your build configuration on the server:

<build-type>
<requirements>
<exists name="env.WEBSPHERE_HOME" />
/requirements>
</build-type>


Great. And I've also noticed the panel on the project page which lists the number of agents which meet the requirements.


If you setup ANT_HOME enviroment variable on build
agent, it will be
sed by our Ant runner. Only libraries will be used,
not ant script.


Makes sense. That would explain why changing the memory usage directly in the plugins/ant/bin/ant script didn't help my problem.

To summarize:

- I could not figure out how to pass java

parameters to the ant builds on the agents.

Use jvmArgs run-parameter (see above).


Great. Worked fine.

- I could not figure out how to pass -D parameters

to the ant builds on the agents.

Use param tag in <parameters> section with system.
prefix


Yeah. I was not putting it in , but instead in ]]>. Thanks.


- 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.

1. configure <requirement> in build configuration
on server, and
2. configure appropriate variable in
buildAgent.properties file on
he build agent.


Haven't tried it yet, but sounds like what I need...mostly.


- I was not happy with having to include my CVS

password in plaintext in the configuration file.

We will support .cvspass file


Awesome.

- 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.

Currently, we use two modes for the build log:
important messages
with status at least WARNING) and all ones.
Additionaly, we redesigned
build log to make it more readable (will be available
in the next EAP
this week). If you'll need better organization of the
log, feel free to
add Jira request.


I'll wait for that and then make comments as appropriate.

- I could not figure out how to use a JDK other

than that used for the agent to do the ant builds.

Use JAVA_HOME variable to point to appropriate
JDK. It will be used
o start Ant. When a build is started, build agent
logs a debug message
to console with path of java executable used.


Great. I'll try it out. Though this gets a little tricky, as JAVA_HOME is going to vary from machine to machine. I guess a possible workaround would be something like setting different classes of JAVA_HOME on the agents and then reference them on the server. Something like:

JAVA_HOME_14=/usr/jdk1.4.2_05
JAVA_HOME_15=/usr/jdk1.5.0_03
JAVA_HOME_15_BEA=/usr/jrockit-j2sdk1.5.0

on one agent machine:

JAVA_HOME_14=C:/jdk1.4.2_09
JAVA_HOME_15=C:/jdk1.5.0
JAVA_HOME_15_BEA=c:/Program Files/Java/jrockit1.5.0

on another and then on the server something like:

]]>

Would that work?

A few other things that come to mind.

- We have integrated checkstyle into our automated build and will fail a build for violations. We have added a panel to CC to display those violations so we do not have to look at the entire log output (which we can't really do anyway, as it causes CC to crap out, but that is another story). We do the same with Macker as well as provide a link to clover output for our nightly builds. What would be the recommended way of making such information available on the build results page?

- Is there a way to modify the parameters used by CVS to do the checkout? We have a minor bug (that I will fix now because of TeamWare) that causes one of the builds to break if empty directories are not pruned.

- We have people who "manage" certain builds and need to receive broken build messages whenever that build breaks, regardless of whether they have checked in code or not. Is there a way to set a default user like that.

- Is there a way to provide support for external tools like Fisheye, CVSWeb or ViewCVS to display more details of the recent modifications? This may become moot as you guys handle more details in your own internal version, but we use this to display a diff of the file modified to make fixes easier.

- Similarly, is there some way to see all code changes in one place since the last clean build? This would be especially useful for build "managers".

- Is it possible to clean up successful builds at a different rate than unsuccessful builds? We leave around successful builds for a month, but clear out broken builds more than a few days old as they do not offer much value after a short period.

--Tim

0
Comment actions Permalink

Tim McNerney wrote:

>>> - I could not figure out how to use a JDK other
>> than that used for the agent to do the ant builds.
>>
>> Use JAVA_HOME variable to point to appropriate
>> JDK. It will be used
>> o start Ant. When a build is started, build agent
>> logs a debug message
>> to console with path of java executable used.


Great. I'll try it out. Though this gets a little tricky, as JAVA_HOME is going to vary from machine to machine. I guess a possible workaround would be something like setting different classes of JAVA_HOME on the agents and then reference them on the server. Something like:

JAVA_HOME_14=/usr/jdk1.4.2_05
JAVA_HOME_15=/usr/jdk1.5.0_03
JAVA_HOME_15_BEA=/usr/jrockit-j2sdk1.5.0

on one agent machine:

JAVA_HOME_14=C:/jdk1.4.2_09
JAVA_HOME_15=C:/jdk1.5.0
JAVA_HOME_15_BEA=c:/Program Files/Java/jrockit1.5.0

on another and then on the server something like:

<param name="env.JAVA_HOME" value="env.JAVA_HOME_15"/>

Would that work?


Not in the current build :(
So far you can only set build parameters and use them for Ant tasks,
like:
... and ]]>

To run Ant, only JAVA_HOME variable, which is set on build agent
machine, is used.
We'll implement custom java home specification, please monitor
http://www.jetbrains.net/jira/browse/TW-307


A few other things that come to mind.

- We have integrated checkstyle into our automated build and will fail a build for violations. We have added a panel to CC to display those violations so we do not have to look at the entire log output (which we can't really do anyway, as it causes CC to crap out, but that is another story). We do the same with Macker as well as provide a link to clover output for our nightly builds. What would be the recommended way of making such information available on the build results page?


No way to do it yet. Please file a request with desired behaviour.
So far you can only generate some html reports and view them via
"Artefacts" page.


- Is there a way to modify the parameters used by CVS to do the checkout? We have a minor bug (that I will fix now because of TeamWare) that causes one of the builds to break if empty directories are not pruned.

- We have people who "manage" certain builds and need to receive broken build messages whenever that build breaks, regardless of whether they have checked in code or not. Is there a way to set a default user like that.


Please vote for http://www.jetbrains.net/jira/browse/TW-66


- Is there a way to provide support for external tools like Fisheye, CVSWeb or ViewCVS to display more details of the recent modifications? This may become moot as you guys handle more details in your own internal version, but we use this to display a diff of the file modified to make fixes easier.


Honestly, no.
In fact, there are some requests to provide more details about
modifications:
http://www.jetbrains.net/jira/browse/TW-77 (Diff on WEB)
http://www.jetbrains.net/jira/browse/TW-79 (navigate from changelist
to bugtracker)
http://www.jetbrains.net/jira/browse/TW-303 (show file revisions in
changelists)


- Similarly, is there some way to see all code changes in one place since the last clean build? This would be especially useful for build "managers".


Next EAP will contain "All changes" view, which will probably solve
this task. We'd be glad to hear your feedback on it!


- Is it possible to clean up successful builds at a different rate than unsuccessful builds? We leave around successful builds for a month, but clear out broken builds more than a few days old as they do not offer much value after a short period.


This requires writing another cleanup policy. Please file a Jira
request for this.


Thanks a lot for the feedback!
KIR


--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.