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

Enable working Travis config #11

Open
balhoff opened this issue Dec 14, 2016 · 2 comments
Open

Enable working Travis config #11

balhoff opened this issue Dec 14, 2016 · 2 comments

Comments

@balhoff
Copy link
Member

balhoff commented Dec 14, 2016

The current Travis config doesn't do anything useful. A working config could test that the build procedure is able to run all the way through; however, the build as specified by the Makefile requires a very large amount of memory to run (~100 GB). We could:

  1. Make the the inputs entirely configurable and build a similar but much smaller database via Travis.
  2. Forget about Travis and automate the build on Jenkins with sufficient resources instead. In this scenario we could run content-specific validations and also deploy the output.
  3. Both.

Opinions @cmungall or @kltm?

@kltm
Copy link
Member

kltm commented Dec 14, 2016

My opinion of Travis has been rather dropping recently. And being able to test the build all the way through sounds awful nice to me considering all of the various problems we've had with the pipeline here and there (extra cool if versioning of the data is involved).
However, I think that the travis builds are meant specifically to deal with code testing, unit tests, and the like, with the jenkins stuff a little bit more towards the data testing and pipeline. It may be that we want to have the lighter code-oriented stuff in travis and data in jenkins anyways.
I think "1" is probably good for some parts, "2" will probably need to happen as well at some point, which pretty much would mean "3" 😢

@balhoff
Copy link
Member Author

balhoff commented Dec 14, 2016

Thanks. Having the makefile work off of a configuration (as in "1") kind of seems like a step too far to me. It is itself a configuration of various other tools. I agree that "2" needs to happen either way.

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

No branches or pull requests

2 participants