ghc-compete, a repository of fingerprints, and continuous integration
Fri Oct 11 10:59:07 UTC 2013
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:
> 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:
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
> So if you click on a specific build result, e.g.
> 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.
More information about the ghc-devs