How does the trac plugin get data from Cruise?

[Paul Julius]

Greetings everyone,

My name is Paul Julius. I co-founded the CruiseControl project.

I was wondering if someone would tell me (I know I am lazy and should
read the code) how the plugin extracts data from Cruise?

I am hoping that it doesn't do any screen scraping. Better options would
be via jmx, rss or the xml servlet.

Thanks,
PJ

[Tammo van Lessen]

Hi PJ,

No worries, there is no screenscraping involved :) TracCC needs access
the the project's log folder. It displays the build status file and
pipes the xml log though libxslt and your stylesheet set.

Unfortunately, libxml2 and libxslt are not part of the python distro,
thats why I'm currently moving away from the XSLT approach to directly
parsing the CC logfiles as the dependencies to native libraries are
pretty error causing. This implies (unfortunately) that I've to do the
rendering by my own. Its good that I'm currently writing to you :) So
I can ask the question that came up during the development directly to
the pro :)

Is the CC XML log file format somehow structured/specified? Especially
the <build> part. I currently have the feeling that each component can
dump its information in a pretty unstructured way, and the only reason
to come to a structured output is in the rule-based nature of XSLs? Or
is there a standard set of element and attributes that indicate: Now a
certain goal is executed, this was an ant task, this was a shell
script etc.?

Cheers,
Tammo

2007/5/16, Paul Julius <pa...@willowbark.com>:

--
Tammo van Lessen - tvanl...@gmail.com - http://www.taval.de

[Paul Julius]

Tammo van Lessen wrote:
...

> Is the CC XML log file format somehow structured/specified? Especially
> the <build> part. I currently have the feeling that each component can
> dump its information in a pretty unstructured way, and the only reason
> to come to a structured output is in the rule-based nature of XSLs? Or
> is there a standard set of element and attributes that indicate: Now a
> certain goal is executed, this was an ant task, this was a shell
> script etc.?

You are right, the cruise log is relatively unstructured. The way the
merge loggers work is they just merge whatever xml you specify as a
subelement of the root element. There's no good way to know for sure
what the entire XML file will contain.

There are some givens, of course. The format for junit test results is
pretty much fixed.

I am, personally, currently leaning away from merging everything into
the cruise log. The logs get too big without any added benefit. The xslt
approach built into cruise's reporting app hasn't really scaled that
well. So, the upcoming dashboard release includes the ability to define
"widgets" that parse other files, not necessarily the main cruise log.
So, you might see less and less merging of miscellaneous xml into the
cruise log.

I hope that answers the question. Let me know if I missed the mark.

- PJ