-----Original
Message-----
From:
jfredrick@xxxxxxx [mailto:jfredrick@xxxxxxx]
Sent: Saturday, November
15, 2003 4:19
PM
To: Robert Pearse
Cc:
cruisecontrol-user@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Cruisecontrol-user] The
Problem With Cruisecontrol
Good news -- most of what you describe are issues
under your control, not problems inherent in cruisecontrol. Quick summary:
1. The reporting does support multiple projects.
2. You get what ant returns, you can do stuff to
change what that is, and you almost certainly have other information in the
log file that you can access with xsl.
3. If you want to you could create a custom email
publisher that would compare log contents and only send email if you were
failing for a different reason. Something short of that is
buildafterfailed=false and spamwhilebroke=true.
4. CC only knows that ant tells it. If ant says the
build failed, the build failed; if an says the build passed, the build passed.
If you want ant to fail when a test fails there are multiple ways to do
that...
1. The web.xml has a parameter called "singleProject"
-- set that to false and you'll be in multi-project mode. In multi-project
mode the logDir param should point to the directory that is the parent for all
the individual project log directories. In fact any directory under the logDir
will be considered to the project name, and that name will be listed when you
go to http://<host>:<port>/cruisecontrol
2. The summary "Java returned 1" is what ant returned
when it failed. The details of the failure should appear below _if_ the
structure matches what one of the .xsl files are looking for. If you ejbc
details don't appear you should take a look at the log file to see where in
the xml structure they're listed, and then create an .xsl file to display
them. compile.xsl is probably a good starting point. Once you have your .xsl
file you can edit main.jsp to include it and create a custom
htmlemailpublisher that includes it by overriding getXslFileNames().
3. If you turn buildwhilefailed="false" CC will only
rebuild if a change has been committed since the last check-in. This option
combined w/spamwhilebroken="true" is a good combo because then everyone gets
feedback from their check-in. IOW even if the build is already broken I may
not know that when I check in. The failure message that results may be a
duplicate for the people who broke the build, but now I know what is going on
too. If you _really_ don't want anyone to get the same message twice you could
do that with a custom publisher, but that's a lot of work for marginal reward
(imho).
buildwhilefailed is an attribute on the project
element:
http://cruisecontrol.sourceforge.net/main/configxml.html#project
4. Ant has two ways (at least) to halt when there is a
junit failure. One is the haltonfailure option and the other is to set a
failure property and then halt using a fail task. The second is usually
preferable as it allows you to know if multiple tests are failing while the
first option only tells you about the first test that failed. So you may want
to try something like:
<junit failureproperty="test.failed ...
<fail if="test.failed" message="one or more tests
failed" />
PS: please don't spam questions to both lists.
Questions list this about about how to use cruisecontrol should go to the user
list.
On Saturday, November 15, 2003, at 10:00 AM, Robert
Pearse wrote:
A couple months ago, I moved our
autobuild system to Cruisecontrol. In the process, I’ve had to deal with the
following problems:
1. Cruisecontrol’s JSP reporting
does not support multiple projects. Our installation has 3 Cruisecontrol
processes, one running one project and the other 2 running 2 builds each.
However, we’re able to get JSP reporting for the CC process running the one
build (our main trunk). I can run a separate WebLogic instance for each
build, but we don’t have the over head for that on the build box. Besides,
that smells like a hack to me.
2. Cruisecontrol is pretty dumb
when it comes to determining build failures. For example, we build for
WebLogic so we use the ejbc target. If that fails, I simply get a “Java
returned 1”.
3. Cruisecontrol is pretty dumb
about differentiating between build failures. The spamwhilebroken attribute
doesn’t differentiate between types of build errors. If Dev A breaks the
build and fixes it, then Dev B breaks the build in a different manner, we
don’t get an email. Cruisecontrol sees the build as broken and will not
notify that it’s broken differently. The only way to fix that is to turn on
spamwhilebroken which is annoying if a Dev is figuring out a tough compile
issue and other Dev’s are still checking in code.
4. Cruisecontrol doesn’t
differentiate between a build failure and a unit test. Failures are
failures. And, it bugs me that I have to sniff for a text file (text file
persists the state of a failed Unit Test) to fail the build if a Unit Test
fails. (note: I realize that this a function of JUnit not halting the build
in the case of unit test failures, but it still bugs me.)
I would love to hear what steps
I can take to fix these shortcomings. Otherwise, my dev team is going to
force me go back to the kludgy shell scripts. Cruisecontrol is much easier
to administer.
