Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Bikeshed: build reports
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
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.
If doc build not attempted:
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.
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.
Summary displayed at top of page, in the same way as in the list, with the build log shown below.
Implement reports list
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
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.