search

allenai / deep_qa

A deep NLP library, based on Keras / tf, focused on question answering (but useful for other NLP too)
Apache License 2.0
404 stars 132 forks source link

Remove CircleCI as it is unused. #380

Closed schmmd closed 7 years ago

schmmd commented 7 years ago

However, it does run for PRs--is there a reason to use both circleci and travis? I noticed we only have a travis badge on the README.

matt-gardner commented 7 years ago

CircleCI is used - we use it for making sure the docs build. I don't remember the initial motivation for using CircleCI for docs instead of travis - @nelson-liu, any help here?

nelson-liu commented 7 years ago

Yeah, artifacts are a lot easier to interact with on circle imo. Also in general I wanted to separate the testing of docs and actual code

schmmd commented 7 years ago

It seems a bit nuts to use two external CI systems that are unsupported by AI2 (other teams use TeamCity and SemaphoreCI)--are you guy interested in consolidating on one or the other @matt-gardner @nelson-liu ?

nelson-liu commented 7 years ago

Fair enough. We were on semaphore before but switched to Travis after making the repo public since Travis can run multiple build jobs and tasks in parallel and was thus a lot faster.

We did make the tests faster so maybe that isn't as much of a concern. If you really want to consolidate, then Travis seems to be better. Thoughts @matt-gardner ?

matt-gardner commented 7 years ago

I definitely don't want to use semaphore, because then we're sharing build capacity with all of AI2, even though the repo is public. I'm not sure that "supported by AI2" makes much difference here, as these external build tools are simple enough to use, and they are free because our repo is public. Our CI needs are simple enough that it seems overkill to run our own teamcity instance for this (and we'd want to have that teamcity instance be public-facing, so that external users/contributors can see the build results in PRs).

I could be convinced to consolidate to just using travis, but I do think it's nice to be able to look at the docs generated by someone's PR to make sure they look ok, without having to checkout their fork of the repo and build the docs myself. You can't do that with travis without a whole lot of headache. Do we really need to consolidate? What overhead does having two systems actually add? It doesn't actually seem crazy to me.

If we want to take the same functionality we get from circle and get it with travis, it would be considerably more overhead than just using circle (either by me, manually checking out and building code, or something like this). On the other hand, I think travis is much nicer for running our actual tests, and I don't much care for circle's interface, so I would prefer to stay with travis for our code checks.

schmmd commented 7 years ago

Thanks for the context. It still seems a bit nuts to me to use two CI systems, but you filled in some missing knowledge.