The above sounds great. I think it would be nice to add some kind of control file to the directories...say something like teamcity.xml...which could indicate behavior beyond the default of creating a tab per subdirectory in the artifacts dir.

Some of the things that come to mind are:

- start page - what file to use initially when the tab is selected - default to index.html
- visibility - some way of indicating conditions where the tab is visible, so that you could display the tab only if there was some problem (say indicated by a file's existence) or the tab is only visible upon a (un)successful build
- ordering - so the tabs come up in a reasonable order
- hierarchy - so you could group certain tabs together in a top level tab

Those are a few off the top of my head. Like I said, this is all just icing. General handling as described by Dave would be a tremendous first step.

I think we could generify coverage report approach when we send zip file with report files as artifact and provide a way to browse this zip file from the web. That allows to reduce number of files in artifacts directory, and will speedup their upload to buildserver.

I don't think it will be difficult for users to insert some code that will archive report files before uploading them to build server.

See http://www.intellij.net/forums/message.jspa?messageID=5181475#5181475 for related discussion on the current issue

I agree with Tim that a little bit of configuration would need to be available. Automatic discovery may work as a default to insure a good "whoa" factor ;-) but customization will make it usable.
I will however push much harder on a summary view than on polished reports views with fancy UI. I have opened a separate issue for that http://www.jetbrains.net/jira/browse/TW-1673
IMHO a summary view with trending will make TC not just a nice CI tool but an indispensable tool to keep medium to large projects under control. But something tells me I am preaching to the choir ;-)

Kirill, you are right on the money here. I was thinking of doing just that with your coverage plugin code. Maybe this could be a collaborative opensource effort?
I need to get off cruisecontrol as soon as possible. Right now I am still maintaining it for to the reports. How early do you think you could start on this?

Jacques

BTW we have used the latest TC EAP for 3 weeks now and its quality (stability, user friendliness, power...) impresses me! It reminds me of the pre IDEA 3.5 EAP days ;-) Right Dave?

I love Tim's customizations idea, and think Kirill's implementation constraint is reasonable.

If another use case is needed (to push the priority beyond "Critical"!) we would like to start doing an automated functional test nightly using TeamCity. This functional test would run for hours, and produces a bunch of log files. We were planning on keeping around in the artifacts directory, where we could then download them and look at them as text files. Wrapping these in a directory and slapping a quick index.html in it would make our flows much easier, and thus make the logs more likely to actually be examined by QA. A major win, for a minor cost.

And Jacques is right. Working with Agra is now giving me the same sort of "this is how software development was supposed to be!" feeling that I got way back in the day working with IDEA 3 for the first time. I was hooked then, and I'm just as hooked now. It may not feel like it as you slog through coding one more damn VCS adapter, but you're changing the way this game is played.

I think we'll try to implement the following: configuration file in TeamCity's config directory which states which directories or zip files to look for in artifacts directory, and how to name tabs, which html file to look for inside this directory.

We'll also probably need to rework UI in some way to make many tabs usable.

I'll try to implement something like that on this weekend, but the EAP is planned not earlier than after the next weekend.
Thanks for your help and contribution!

Outstanding! I can't wait to try it out.

OK, here is how it will work in the next EAP.
If you need to view some HTML report generated by third-party tool in your own TeamCity tab, you need to do the following:

1. In your build script, add a task which archives your whole report into some zip or jar file. Let's name this file "report.zip"
2. For the build configuration, which produces such a report, add "report.zip" to Artifact paths of this build.
3. In $HOME/.BuildServer/config/main-config.xml add the following line within <server> tag:

<build-tab title="A Report" basePath="report.zip" startPage="index.html" />

 In this line, "title" is title of the tab and it should be unique, "startPage" specifies relative path of start page within zip file.

 Side note:
 -------------
 In fact, TeamCity allows to obtain a file from any zip/jar archives from build artifacts directory:

Supported URL pattern 1: /repository/archive/coverage.zip/buildId/43/index.html
   43 - build ID of the build
   coverage.zip - name of file to get content from
   index.html - path of the file to obtain from archive

  Supported URL pattern 2: /repository/archive/coverage.zip/buildTypeId/bt2/buildId/(lastFinished|lastSuccessful|lastPinned)/index.html
    bt2 - build type ID
    lastFinished or lastSuccessful or lastPinned - identifier for the build instance

  Supported URL pattern 3: /repository/archive/coverage.zip/buildTypeId/bt2/buildNumber/someBuildNumber/index.html
    bt2 - build type ID
    someBuildNumber - build number

Change:
You'll have to use report-tab tag instead of build-tab:

<report-tab title="A Report" basePath="report.zip" startPage="index.html" />

Addition:
You can use directory name in basePath attribute, and startPage will be taken from this directory. Archive-based access is still supported.

Kirill,

This is awesome! I just upgraded and configured the new version. It rocks!
Now we just need a way to do TW-1756

Thanks again!

I'm not sure if this issue will be reopened based on this comment, or if I should submit a new issue, but hopefully someone will pick it up.

I would like an additional parameter for the <report-tab> element. I want to be able to specify if the report should be opened in a new window/tab. I have implemented a Sandcastle report, but because of the javascripts for the report, the url is relocated to Index.aspx. If i modify the script to relocate to http, it will flicker because its' trying to reclaim the IFrame (i think).

Bjørnar,

I've created a new issue to handle the case: TW-2938
Let's comment on it there.