Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Experimental Stack-based Travis-CI (DO NOT MERGE IT) #162

wants to merge 1 commit into from

Conversation

rbasso
Copy link
Contributor

@rbasso rbasso commented Jun 24, 2016

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:

  • Locally reproducible test with automatic handling of dependencies, multiple version of GHC and packages snapshots. ✅
  • It automatically tests for newer versions of compilers and packages, allowing us to be notified of problems and prepare earlier for changes. ✅
  • We get the ability to enforce correctly specified dependencies for each of the exercises for free. ✅
  • Playing with new tools is good for learning. 😄
  • There is no loss if it fails completely. 👍

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.

Move to independent, isolated tests based on stack.
Uses the script `stackalize` in _test to generate
individual projects for each exercise.
@petertseng
Copy link
Member

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

@petertseng
Copy link
Member

stack tests both with/without stack: https://github.com/commercialhaskell/stack/blob/master/.travis.yml

@rbasso
Copy link
Contributor Author

rbasso commented Jul 3, 2016

I think there are two obstacles to implementing a hybrid solution:

  • Conditionally install dependencies and run test. - Easy, but ugly!
  • Change bootstrap.sh to use dependencies.txt as source. - Hard and ugly!

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:

  1. Change bootstrap.sh to use _test/dependencies. This has it's own merit, centralizing all dependencies in one place.
  2. Finally, the hybrid tests.

I see that you already have a PR for this, so let's discuss the details there.

@petertseng
Copy link
Member

Change bootstrap.sh to use _test/dependencies. This has it's own merit, centralizing all dependencies in one place.

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.

@rbasso
Copy link
Contributor Author

rbasso commented Jul 3, 2016

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. 😄
If you want to write it, please do it. Today I'm kind of busy and it's 33C here, so I'm not thinking clearly. 😅

@rbasso
Copy link
Contributor Author

rbasso commented Jul 3, 2016

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.
Just let me know when you are comfortable with merging #179 and then #174. 👍

@rbasso rbasso closed this in #174 Jul 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants