search

reflex-frp / reflex-dom-semui

A reflex-dom API for Semantic UI components
https://reflex-frp.org/
BSD 3-Clause "New" or "Revised" License
22 stars 10 forks source link

Set up CI with Travis #7

Closed mightybyte closed 7 years ago

mightybyte commented 7 years ago

Since we want this project to build with both GHC and GHCJS we should set up Travis so it builds with both of those. That way contributors don't have to remember to test with both. I'm not sure of the best way for getting Travis to work with GHCJS, so this ticket might take a little research.

imalsogreg commented 7 years ago

I just pushed something I've been using to the travis-test branch. I don't seem to have access on travis-ci.org to turn on testing for this repository - could you hit the switch for me @mightybyte?

spl commented 7 years ago

I haven't looked at @imalsogreg's stuff, yet, but I have set up stuff to build with stack for both GHCJS and GHC. If you want that, I'd be happy to do it.

mightybyte commented 7 years ago

I just turned Travis on for this repo. See if it works for you now. If you've both got something in mind, maybe negotiate between yourselves the best option?

imalsogreg commented 7 years ago

Hi @spl! How do you like to test? My script installs reflex-platform, which lets us use the cached ghcjs stuff. If the stack script handles caching too, that may work. Are there some other advantages of testing via stack, like maybe building against different stackage snapshots?

spl commented 7 years ago

@imalsogreg: I think what you have is mostly fine. A couple of comments:

By “cached ghcjs stuff,” do you mean the Travis CI cache of the build of GHCJS? You can also do that with stack by caching the ~/.ghcjs directory.

The advantage of stack might be allowing you to use different snapshots, compiler versions, and dependency versions (e.g. by using a different stack.yaml for each). At this point, I don't think it's necessary. It might useful later to test multiple versions of GHCJS, GHC, ghcjs-dom, etc.

I'm not sure what the BENCH, TEST, ENCRYPTION_LABEL, and COMMIT_AUTHOR_EMAIL env vars are for.

One thing I've found helpful in catching errors in the cabal packaging process is to test the sdist rather than the repository itself. (During development, I think people regularly run the tests in the repository, but they rarely run the tests of the package as it would be uploaded to Hackage.) See, for example, spl/dlist@ea94dc70aa110ba493ee0b3354c1fb7d894644f2. The basic idea is to do cabal sdist, cabal unpack, cd into the unpackaged package, and do the build and test there. I used git tags to determine the version, but maybe there's another way to do it if you're not using tags. (Though I think it's a good idea to use tags anyway for release referencing.)

mightybyte commented 7 years ago

👍 to testing the sdist. sdist problems have bitten me in the past.

imalsogreg commented 7 years ago

@spl: +1 on the sdist build, and thanks for the example from dlist. I'll try to bring that over now. I see hvr's multi-ghc-travis does a: cabal info . | awk '{print $2; exit}', which will give us the the versioned sdist build directory until we make a git tag.

By "cached ghcjs stuff" I only meant the nix cache from reflex-frp.org.

The environment variables you mentioned are old cruft that indeed don't make sense in this file :)