-
-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental Stack-based Travis-CI (DO NOT MERGE IT) #162
Conversation
Move to independent, isolated tests based on stack. Uses the script `stackalize` in _test to generate individual projects for each exercise.
One advantage of merging this is that we wouldn't have to do things like #172 because Travis would test that for us. But the disadvantage would be losing 7.6 in CI, is that right? That is a real shame; were it not for that, I'd be in favor of merging. I know in #153 the idea of "as a special case let's test 7.6 with plain cabal and not Stack" was brought up though I haven't explored what that looks like yet. Maybe it'd be worthwhile to take a look at what some other projects do with this and how they manage the resulting complexity. Now, it's true that the maintenance burden of keeping this PR up to date with master is currently handled by you, so nobody else has to deal with that. It would still be good to resolve the tension, though, and to get the advantage of getting our dependencies checked. So why don't I do some exploring for the hybrid solution, we see what it looks like, then figure out what to do |
stack tests both with/without stack: https://github.com/commercialhaskell/stack/blob/master/.travis.yml |
I think there are two obstacles to implementing a hybrid solution:
I'm in favor of pushing users to use never GHC versions, mostly because I believe that people should get used to how Haskell code is actually being written (ghc-7.10.3 and ghc-8.0.1, stack and cabal sandboxes), but also to make xhaskell more maintainable. That said, I agree that we can have a mixed solution, so we can postpone the decision of dropping ghc-7.6.3 until we think it is time to let it go. I propose to merge the mixed solution in two phases:
I see that you already have a PR for this, so let's discuss the details there. |
That seems good. Will you do this or should I give it a try? Might be worth a separate issue to keep track of this task if you think it's worthy. |
Definitely worthy it's own issue. 😄 |
That was fast, @petertseng! Congrats! 🎉 With #179 and #174 I guess we will be fine with a mixed Travis configuration. 😄 Let's just make quick a comparison so that we have an idea about the price we are paying for ghc-7.6.3:
I'll trust your judgement in this one. |
As we add dependency control at the source level with #159, It turns possible to automatically build and test each exercise in a sandbox with Stack inside Travis-CI.
There are some good reasons to experiment with this solution:
The idea is to keep this pull request always based on master without being merged, so we can compare how it performs with our actual solution and correct any dependency change not correctly specified in
dependencies.txt
.If the test are successful, merging this would:
Also, #124 is affected, because stack doesn't support GHC 7.6.3, and we would have to quit testing with it.