NCover code-coverage reports, part 2#979
|
|
The other problem I have with NCover full-reports, of course, is that they are ~500Mb big, and the product is still small. Will Cruise start intelligently compressing artifacts for storage, please, as part of the receive-artifacts mechanism? That is, if an agent wants to publish an artifact that is compressible, the server will happily receive and compress it? Or, perhaps instead, it will compress a job’s worth into a package? I mean, my users will not look at every artifact. The trade-off is cost of storage vs speed of retrieval, clearly. I’m not really sure what the answer is – perhaps simply gz incoming artifacts for on-disk storage – it’s a truly rare business environment these days that doesn’t mandate browsers that can support Accept-Encoding: deflate/gzip, so I think it would be pretty safe to store stuff at least gzip’d. Another way around this might be something a bit lateral. Allow a server admin to set up a dynamic artifact – that is, instead of simply publishing a static file, the server-admin can specify that Cruise run something to deliver the artifact that is requested. This could allow me to publish just the XML basis for my report (which is only 500Kb) and then allow people to request fragments of it on-demand via the transform of XML with XSLT (since NCover ships the XSL that it uses to generate the full HTML report). So this feature would allow me to specify that Cruise loads some external web-page (say) with a querystring to be the initial entry point into the report, and from there the external web-page takes over. |
|
|
That is an insane amount of data. There are a few things here:
Jez. |
|
|
That would be nice – the NCover guys provide XSLs for this, and given that we do internet TV, everyone who’s going to be looking at the Cruise site is going to have a browser capable of XSLT. If Cruise could be told that it should use this XSL on that XML to build a meta-site (for wont of a better term) inside a tab, that would be really rather slick. |
