This project is mirrored from Pull mirroring updated .
  1. 21 Aug, 2016 3 commits
  2. 20 Aug, 2016 1 commit
  3. 18 Aug, 2016 2 commits
  4. 17 Aug, 2016 6 commits
  5. 16 Aug, 2016 1 commit
  6. 14 Aug, 2016 1 commit
  7. 13 Aug, 2016 1 commit
  8. 11 Aug, 2016 8 commits
  9. 10 Aug, 2016 7 commits
    • Federico Mastellone's avatar
      Merge pull request #3688 from haskell/issues-3687 · a89e5482
      Federico Mastellone authored
      AppVeyor fails installing GHC 7.10.3
    • Federico Mastellone's avatar
      AppVeyor fails installing GHC 7.10.3 · da051653
      Federico Mastellone authored
      This fixes #3687
      Swithed AppVeyor test to GHC 8.0.1 because 7.10.3 is broken ( and added the `-y` option and `refreshenv` after installing GHC as suggested by Chocolatey
    • Duncan Coutts's avatar
      Rework reportBuildFailures to include build logs · 5fe5202b
      Duncan Coutts authored
      Reporting build logs is important as we otherwise have no real info for
      why deps failed to build. It does make the presentation more difficult
      however because build logs can be long and in principle there can be
      several, which means it can take up more than a single screen in a
      console. The first thing users notice is typically the last few
      messages, so in the case that we're presenting long build logs then its
      important to also include a short summary at the end.
      So our approach is this: for packages where we want to show a build log,
      we dump those first, in full, each with a header to indicate which
      package it is, log file name (for later reference), plus any extra
      detail we have from the phase of the failure or the exception. Then
      after all build logs we end with a short summary of the failure(s). For
      packages where we do not show a build log (e.g. local packages that dump
      live to the console) we only present a summary at the end, but we
      include a little more detail than for the packages that had a build log
      since this is the only thing we report for them. So we include details
      of the exception.
    • Duncan Coutts's avatar
      Remove PlanningFailed and add {Repl,Haddocks}Failed · bfdd9539
      Duncan Coutts authored
      The PlanningFailed case does not happen. The ReplFailed, HaddocksFailed
      cases were previously covered by BuildFailed but they're worth
    • Duncan Coutts's avatar
      Add the build log into the Build{Result,Failure} · 11ed1709
      Duncan Coutts authored
      In both cases it's optional and only added when the log file is used.
      This will be used later in reporting the build outcomes.
    • Duncan Coutts's avatar
      Redefine the Build{Result,Failure,Outcome} types locally · 6421c3e2
      Duncan Coutts authored
      We're going to alter and extend the BuildResult and BuildFailure types
      for the new-build code, so we cannot share those types with the old
      install code.
      This patch doesn't change the structure, just redefines them locally and
      switches uses to record style so we can add new fields easily.
    • Duncan Coutts's avatar
      Rename BuildResult/BuildOutcome, BuildSuccess/BuildResult · 2a0505c7
      Duncan Coutts authored
      I think these names are now a bit more induitive / less confusing and a
      bit more consistent.
      We now have BuildOutcome(s) to mean either failure or a build result,
      and BuildResult to mean the result of a non-failing build.
  10. 09 Aug, 2016 1 commit
  11. 08 Aug, 2016 3 commits
  12. 07 Aug, 2016 6 commits