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
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
- 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. 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
- how should the public api of GenerateBuildDashboard task look like? Is
something like that ok:
task generateMyDashboard(type: GenerateBuildDashboard) {
aggregate reportingInstance1, reportingInstance2, ...
}
- what should be used to actually generate the html of the build
dashboard? A templating engine, builder etc.?
That's all that comes to my mind at the moment. Seems to me that if we
sort the above out we will be able to get the first iteration which
would result in generating a simple dashboard HTML report that links to
the reports declared in the build done.
Cheers,
Marcin
