JUnit XML Skeleton fits for Hudson

Hudson built-in supports JUnit XML reports. But unfortunately, the thing I want Hudson to show is neither written in Java, nor generate by JUnit, yet I managed to create a minimal JUnit XML that is accepted by Hudson. Here is how it looks like:

<?xml version="1.0" encoding="UTF-8" ?>
<testsuite errors="1" failures="1" hostname="HOSTNAME" name="PACKAGENAME" tests="3" time="3.0" timestamp="2010-06-30T05:16:00Z">
  <testcase name="TESTCASE1-SUCCESS" time="1.0" />
  <testcase name="TESTCASE2-ERROR" time="1.0">
    <error message="ERR_MSG">STACK_TRACE</error>
  </testcase>
  <testcase name="TESTCASE3-FAILURE" time="1.0">
    <failure message="FAIL_MSG">STACK_TRACE</failure>
  </testcase>
  <system-out>STDOUT</system-out>
  <system-err>STDERR</system-err>
</testsuite>

Replace all uppercase text strings with your strings, and attribute time,failure,error with real values.

[Perl] Beware of carriage-return, even in *nux haven.

Recently I have been using a perl script to analyze returned header from curl and produce a JUnit XML reports.

One small thing that bother me is that it keep generating unnecessary newlines. Of course, I have tried chomp() and couple of similar techniques, but no prevail.

Finally, I though it might be caused by carriage-return (\r) and fixed script accordingly, and it worked as expected.

There is a good document, Why chomp() is not considering carriage-return, provides why chomp() does not process carriage return and how to get around it. But look, there are some carriage-return floating around, especially from web.

[cdash hudson] Google, you have overdone it again!

Yesterday I go Google for searching the articles about cdash – web interface for cmake/ctest – and hudson – an extensible continuous integration server.

However, Google insisted that what I really want is the airplane crash in Hudson river, see the screenshot:

Even in the section that suppose to show the result of cdash hudson.
Yeah, I know the workaround is to adding additional keyword, such as “cmake”.
But, come on, don’t try to outsmart users. 🙂

[Selenium] Converting XPath locator with CSS.

According to selenium’s web site, CSS locator is not only powerful, but also fast.
But despite of that, I was hesitated and kept using xpath, mainly because I hadn’t had idea about how to search by innertext.

Until yesterday, I find that the pseudo class :contains() suit my need. Even better, it supports regex, yay!

But the main push is that XPath is incapable of dealing with certain tags, such as <span>, <label>.

So CSS, here I come!

Converting xscreensaver to gnome-screensaver in Fedora 13

gnome-screensaver is more stable than xscreensaver (Occasionally I have been lock out by it), yet the default collection of savers is not as rich.

There are several of instructions of how to do this, including:

Can I use xscreensaver “hacks” with gnome-screensaver? and

Add xscreensaver to gnome-screensaver in Fedora Core 6. But their information is somewhat outdated.

Here is my instruction for F-13, referencing this post:

1. Install xscreensaver-<whateveryyoulike>. (You do want the richness of xscreensaver savers, don’t you? 🙂 )

   # yum install "xscreensaver-<whateveryyoulike>"

2. link the xscreensavers binary to gnome-screensaver
   # ln -si /usr/libexec/xscreensaver/* /usr/libexec/gnome-screensaver/
-i is for interactive, there is one saver which exists in both gnome-screensaver and xscreensaver.
3. Download the migrate-xscreensaver-config.sh script for migrating xscreensaver to gnome-screensaver, as well as the xsl file it needs.

,

1. Assuming you put these files in /tmp, run
   chomd +x /tmp/migrate-xcreensaver-config.sh
2. Convert xscreensaver config files (.xml) to gnome-screensaver config files (.desktop):
   # /tmp/misgrate-xscreensaver-config.sh \ /usr/share/xscreensaver/config/*.xml
3. Restart X server. This can be done by logout-login if you are using GDM or KDM.
4. That should be it.

[Update] Some user suggest to use xscreensaver-extras-gss , which should be more simple and easier.