On 15/11/2012, at 10:06 AM, Marcin Erdmann wrote: > Hi all, > > I've started working on some stuff based around the design spec > @https://github.com/gradle/gradle/blob/master/design-docs/reporting.md
Excellent. > and have a few questions that don't seem to be covered in the spec. > > You can have a look at the code I managed to produce in my fork in > reporting-improvements branch > (https://github.com/erdi/gradle/tree/reporting-improvements). Basically it's > just a sketch of the task with only inputs and outputs specified and without > any implementation. The plan was to see how far I could get without any major > conceptual problems. Obviously I plan to add tests to it when I'll find the > answers to my questions. > > The following are the problems/questions I have: > > - Test task doesn't implement reporting so it won't be picked up by the > plugin when collecting all the reports to be put in the build dashboard I forgot to put that in as a story. We'd need to either: * Change Test to implement Reporting, or * Split out a separate TestReport task that implements Reporting, or * Have GenerateBuildDashboard task know about Test task type. > > - given the fact that GenerateBuildDashboard task should take a set of Report > instances as input (as per design doc) it is impossible to generate any > useful information in the build dashboard report about the reports apart from > the name (which is usually html, xml or text) and path. It is impossible to > link a report to a task that has generated the report. Why do you want to link a report to a task? To get a better name for the report? Or something else? > Should we use Reporting instances as input to GenerateBuildDashboard task and > add something like getName() method to the Reporting interface? Or should we > assume that Reporting (probably should be called ReportingTask then) will > only be implemented by tasks and get a meaningful name for the sections of > build dashboard from the path of the task? > > - should all files from the enabled Reports passed as the input to > GenerateBuildDashboard task be used as @InputFiles for that task? The obvious > choice for outputs seems to be the build dashboard html file The contents of the files aren't really inputs to GenerateBuildDashboard. It's the destination path that is the input. That is, if the check style report is moved from build/reports/checkstyle.xml to build/checkstyle/report.xml, then we need to regenerate the dashboard report. But, if the contents of the check style report changes, then the dashboard report doesn't need to change (at this stage). > > - how should the public api of GenerateBuildDashboard task look like? Is > something like that ok: > > task generateMyDashboard(type: GenerateBuildDashboard) { > aggregate reportingInstance1, reportingInstance2, ... > } That looks fine. > > - what should be used to actually generate the html of the build dashboard? A > templating engine, builder etc.? What would you like to use? It has to be fast, as this report, when enabled, will be generated for pretty much every build. At some point, I'd like to sync up the test report, profile report, build comparison report and build dashboard report so that they all use the same rendering infrastructure, but that can wait. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
