Add travis build matrix config.

[diogob]

I have kept only the stack tests in the matrix for the sake of simplicity, but I can add back the commands to ensure a build with cabal (although rerunning the tests using cabal seems unnecessary).

I changed some code in order to compile all tests. Now everything compiles but some tests are still failing.

Let me know what you think.

[agentm]

Ugh- I temporarily forgot about nix/stack failing to find the GHC libraries necessary to test our scripting support. I will have to look into that again.

[diogob]

@agentm I can try to figure out this dependencies, do you know exactly what are the missing libraries, paths or binaries?

[agentm]

Thanks! I probably won't have time to dig into this until after the Christmas break.

The issue is that the tests require access to the various GHC-built libraries (including GHC and project-m36 Haskell packages). I have this working for cabal sandboxes and I thought it was working for stack as well. You can see where our binaries look for the modules here. Presumably, the fix would require an additional path be added to the list.

Finding the correct library path on a machine to which you don't have ssh access will be challenging, needless to say, so don't feel discouraged if you can't find it. It's complicated to use GHC-as-a-compiler-service.

I have been toying with the idea of using an off-the-shelf Haskell alternative like Morte which would lower the dependency bar and allow for relocatable libraries (Haskell packages cannot be currently moved), but I haven't found anything suitable yet.

[diogob]

Done! It's probably not the best solution since we could have some corner case where multiple stack snapshots will match the glob function, but is good enough to get the suite running on travis (as well as in my local machine) :D

[agentm]

I read the docs on this flag, but I don't quite understand how the behavior will change. Could you explain with an example?

[diogob]

To be honest I haven't tried without the flag, I just copied from the haskell-stack-travis-ci repo. But the idea is to fail the build as soon as any job fails.

[agentm]

Ok- that's fine with me. Either way, it's not a deal-breaker.

[agentm]

Fantastic! This looks great! I will look to merge it by the end of the week. Thanks for finding the proper paths!

[agentm]

Won't this only build the tests? Before, we were building all binaries including examples and the haddock target.

[diogob]

This will build and execute the tests. It won't build the haddock target though. I can add the haddock at the end of the build if it builds within our time window.

[agentm]

I was expecting GHC 8.2 building to fail, so I am surprised that GHC 8.2 building is working here. Specifically, I know there are some incompatibilities with using GHC-8.2-as-a-library which have not been merged to master. Do you know what's going on?

[diogob]

About the 8.2 build, I'll try to run it manually and see if I can reproduce this build locally.

[agentm]

stack refuses to build with GHC 8.2 in our master branch because the stack.yaml doesn't include a plan for it:

Compiler version mismatched, found ghc-8.2.1 (x86_64), but expected minor version match with ghc-8.0.2 (x86_64) (based on resolver setting in /home/agentm/Dev/project-m36/stack.yaml).

This suggests that this configuration is building with all the same version GHC compiler.

[agentm]

From the travis log:

$ echo "$(ghc --version) [$(ghc --print-project-git-commit-id 2> /dev/null || echo '?')]"
/Users/travis/.travis/job_stages: line 57: ghc: command not found

This suggests that stack is not picking up the installed ghc and using its own. In the same log for GHC 8.2.1:

Linking /Users/travis/.stack/setup-exe-cache/x86_64-osx/tmp-Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 ...

so all the builders are using GHC 8.0.2, probably installed by stack.

[agentm]

Looking at the travis template, shouldn't it be using stack --system-ghc?

[diogob]

@agentm yes, this script is compiling everything under 8.0.2. I'll try to change the stack flags. Worst case scenario I'll create separate stack.yml files

[agentm]

Thanks for the update!

I see now that the macos builder is improperly succeeding because stack is still downloading GHC 8.0.2 there. I think the fix is to install GHC via stack setup $GHCVER on darwin.

The 7.10.3 builder is failing due to a missing version macro- I'll try to reproduce and fix that locally.

[diogob]

I have used the brew version on osx to use the system ghc flags. It is currently working, we can change this later to make it ghc version specific, since now it is bound to whatever version is available in brew (currently 8.2.2).

[agentm]

Thanks! Would it be easier to use stack to download the proper version? We don't support GHC 8.2 yet in the master branch.

[diogob]

@agentm true, maybe it's better to keep the mac build just using the standard stack.yml setup. I'll move the osx conditional to the test command.

[diogob]

@agentm another question, do we want to allow 7.10.3 and 8.2.2 to fail without failing the build? So they would become informative only.

[diogob]

I have rebased to clean a bit the commit history since most commits were just experiments.

[agentm]

GHC 7.10.3 should be supported on all platforms. I used GHC 7.10.3 on darwin just a few days ago but I built with cabal new-build, so something about the stack build is not passing the macro down. I'll take a look at that. For now, I would prefer to disable GHC 8.2 building- I don't want to give the impression it is supported (yet).

More specifically, we have to wait for an upstream package (distributed-process-systest) to bump some version bounds on hackage before we can support GHC 8.2.

[agentm]

stack won't build with GHC 7.10 without a dedicated yaml file since the master branch mentions the GHC 8.0 LTS one. I am testing a GHC 7.10-specific stack.yaml now.

[agentm]

I patched the master branch in e0e4787 to allow for compilation with stack + GHC 7.10 + 6.35 LTS from stackage.

[agentm]

We will have to wait until the backlog is cleared to continue. Even when we get macos time, it's so sluggish, it's useless.

[diogob]

@agentm we are green! Now with the timeout feature the dependencies will be partially uploaded even when the build fails.

[diogob]

I can rebase this to clear the history from experimental commits, what do you think?

[agentm]

Could you comment on how the dependency installation timeout works? If the dependency installation takes longer than 15 minutes, what happens in the Travis UI?

[agentm]

Sure, you can rebase if you like, but the history of our experiments could be useful too. When I merge to mater, I would just add --no-ff to reduce log pollution.

[diogob]

@agentm when the dependencies timeout the build will be red (as failed, not errored). A message about the dependencies timeout will show up in the logs. From then one can hit the rebuild button (if they are collaborators in the repo) or just send another push to trigger a new build and incrementally build the cache.

[diogob]

Once this is in master the failures due to dependencies timing out should become rare, since new pull requests use the master branch cache according to Travis docs.

[agentm]

Great news! I didn't realize that failed builds will also upload the cache.

I hope travis can resolve the macos build backlog soon.

[agentm]

Thanks again for your hard work on this issue! We both got close to giving up but successfully bounced ideas back-and-forth until we got it.

This patch will help us to catch stackage LTS mistakes which I have missed in the past.

The hassles we faced here make me even more worried about the mess the automated Windows builders will face. Next stop: AppVeyor!

[agentm]

@diogob, I am having trouble with dependency-building timeouts in the master branch after 3 commits. Is there anything I need to do to prime the cache?

[diogob]

there is an error that is invalidating the macos build:

/Users/travis/.travis/job_stages: line 57: shell_session_update: command not found

But for the linux build I don't have an explanation, unless their cache upload is coupled with the global state of the build.

[diogob]

I'm making some tests on a branch of my own

[diogob]

I found this: travis-ci/travis-ci#6307

[agentm]

The macos builds are backlogged for over 16 hours, so we probably won't have complete macos builds for a while. I am experimenting with increasing the dependency timeout to prime the cache. For whatever reason, I don't see a cache upload after a timed out dependency step.