Bikeshed: build reports

Use cases

• Maintainer: The documentation hasn't come up yet. What's wrong?

  • Build status
  • Link to latest doc builder report
  • Only include reports submitted by the doc builder

• User: I want to use this package. Will it build on my machine?

  • Build date
  • Link to latest report, regardless of origin
  • Include all reports, regardless of origin

Tentative design

Build status is split into two sections:

• One section is targeted at maintainers. It only checks reports from the Hackage build bot. The question is: Why doesn't this package have docs?

  • We ascertain the source via a "doc-builder" flag in the report type. Only reports from the bot include this flag.

• The other section is targeted at users. It checks reports from all sources, regardless of origin. The question is: Will this package build on my system? While this is undecidable in general, report data is a good approximation.

Documentation status

If doc build not attempted:

Docs pending

If doc build failed:

Docs not available [log]

If docs uploaded manually:

Docs uploaded by maintainer [log]

If doc build passed:

Docs available [log]

• Only one successful report should be needed for "succeeding" status. A missing C library, or Cabal hell, or a cosmic ray triggering a bug in the CPU shouldn't be reason to invalidate the whole package.

• Date is necessary, since old packages may not build any more.

Build summary

If there are no reports yet:

Unknown [no reports yet]

• "no reports yet" links to reports list.

If all reports are failing:

No successful builds reported [all 2 reports]

If there is at least one passing report:

Last success reported on 2014-05-05 [all 3 reports]

List of reports

Simple list of entries. A key/value list, like the attributes on the package front page, should be enough.

Dependencies should be in the form PACKAGE == VERSION, for consistency and copypastability.

It would be nice to have a "Generate cabal.config" button next to the dependency list, so that users can easily reproduce the build.

Individual report

Summary displayed at top of page, in the same way as in the list, with the build log shown below.

Plan

• Implement reports list

• Rewrite parser

• Add a date field

• Implement individual report display

• Add status indicator to package page

• Add "is doc builder" flag

  • Modify status indicator to use this

Really far off ideas

• Travis integration -- so we can report test results as well

• HPC coverage

IRC meeting 2014-06-11

• Important question is "Why did the docs fail to build?"

  • To answer this, add an "is doc builder" flag to the report. Only clients with permission to upload docs can provide this field. Status indicator links to the latest report with this flag set.

• Add timestamp to reports, at least for non-anonymous ones.

• Build report parser needs to be re-written eventually.

• Distinction between "anonymous" and "non-anonymous" reports

  • They must be treated differently, since there can be literally heaps of the former
  • Ignore anonymous reports regarding solver failures -- too much newbie spam

• cabal-install doesn't generate reports on solver failures. It would be nice to know which combinations of dependencies work and which don't, so we can adjust the package file to suit.