Builds timed out. Could someone re-run them if that's the issue?

I restarted the timed out build.

4/5 ran within time this time through...

If you need to restart the build and don't have access to it on Travis, you can close this PR and open it again. It will restart the build.

I think it means all builds will run again, but it beats waiting for someone else to come along.

No, please don’t do that - instead push an empty commit (as the CI log should suggest). As far as I’m aware that’s the only way to get travis to reuse the progress it made during its previous attempt.

I've restarted the failing job a couple of times fwiw 😕

Restarting jobs which have timed out is generally not very effective in my experience; we should be encouraging the submitter to push empty commits instead.

(Instead of empty commits you can regenerate your existing commit with git commit --amend --no-edit - this new commit will have a different commit hash. Then force push.)

An alternate to any of our suggestions could be focusing on making CI more reliable 😄.

Amending and force pushing doesn’t work either. I think Travis must take the cache from the parent commit each time.

Incidentally I spent quite a lot of time on this script and I’m fairly confident it’s the best we can do without moving to a different CI platform.

The previous amend was to address some mistaken code being added, let's see an empty commit

I’m fairly confident it’s the best we can do without moving to a different CI platform.

Just to expand on this a little: I will accept without reservation that this is a pretty sorry state of affairs. I would love to be proven wrong on the above but unfortunately I really do think it’s very unlikely.

Looks like we build the haddocks for dependencies of every job in the matrix whether it has BUILD_TYPE=haddock or not. The job that's failing doesn't have BUILD_TYPE=haddock. Given that it's timing out when uploading the cache–almost done with the build–that extra time with the haddocks is probably enough to push it over the limit. Should we change the jobs to only build haddocks when necessary?

Is it this line?

I'm more than willing to submit a PR for it.

@joneshf I applied that suggestion in my fork here purerl@5b656c8 - not quite sure if it helped or I just had stuff cached by this point, but I think by my understanding this should be right - I believe the cache will be separate for the different entries in our build matrix

Sorry for the delay in responding. Good spot - yes I think that would help.

Heyy, this passed now :)

Cleaned up now. I can rebase #3383 later, and I think I might implement Row.Contains also since sometimes I've needed that and it's similar to the old RowLacks that was expensive as a library

Some of the BreakOn and Contains stuff is still in this PR, @justinwoo ?

Finally removed it