ghc-compete, a repository of fingerprints, and continuous integration

[Simon Marlow]

On 07/10/13 22:06, Joachim Breitner wrote:
> in the best scratch-an-itch-tradition I have created a special git
> repository, called ?ghc-complete?, which tracks the combined state of
> all GHC-related repositories. It uses GHC?s fingerprint utility and
> simply tracks the change of the fingerprint file over time:
> https://github.com/nomeata/ghc-complete
>
> The main use of this is to have a repo which I can enable to be
> continuously checked by Travis (a free CI hoster). So instead of having
> several people ask on IRC about what build or test suite failures are
> actually not their fault, they can now simply check the travis page:
> https://www.travis-ci.org/nomeata/ghc-complete/builds

This is great.  With a bit of extra tool support for this we could 
actually do without submodules and go back to individual repos. 
Checking out a GHC revision in the past could consist of querying your 
ghc-complete repo for the fingerprint and then running the fingerprint tool.

(unless you haven't guessed, I'm not a huge fan of submodules)

> The Travis tests are a bit stripped down, in order to finish reliably
> before the 50 minute timeout, see
> https://github.com/nomeata/ghc-complete/blob/master/validate.sh for the
> precise options.

Did you try with and without -O0 for stage2?  Last time we tried it was 
actually faster to turn on -O for stage2 if you're also running tests, 
because making the compiler run faster outweighs the time spent 
optimising it.

Cheers,
	Simon


> The log files are too large for the JavaScript enhanced view on Travis.
> So if you click on a specific build result, e.g.
> https://www.travis-ci.org/nomeata/ghc-complete/builds/12216328
> then better immediately browse to the raw build log (the rounded square
> button in the top right corner with the four horizontal bars).
>
> Another use of this repo might be bisecting a problem.
>
> If you find this useful, I?d propose to let this run on git.haskell.org
> proper, and also not as a cronjob (every 15 minutes at the moment), but
> rather triggered by the actual pushes.
>
> On my TODO list is to make the commit messages of the repository more
> useful, by including the log of the new commits in it.
>
> If (not sure if this is planned to that extend) eventually all related
> repositories of GHC are submodules, this will have become obsolete.
> Which of course is fine.