search

ropensci / neotoma

Programmatic R interface to the Neotoma Paleoecological Database.
https://docs.ropensci.org/neotoma
Other
30 stars 16 forks source link

Failing travis build. #199

Closed SimonGoring closed 9 years ago

SimonGoring commented 9 years ago

We're getting a failure on travis build 99, but the previous build worked fine.

I just ran the tests and checks on my computer and had no failures, there's no reason the test should be failing. It's also not entirely clear to me which test it's actually failing. I assume it's a test in `test_simple_paper.R, but they all passed fine for me as well.

Not sure what's up. I made a super minor change with commit 475a43dfd0521abe2a0652be2fb342c9d3dfe8a6, basically to see if Travis would pass this time. It didn't.

SimonGoring commented 9 years ago

I wonder if this is the same problem as we had with issue #160 where somehow we hit a limit on downloads and the build failed, even though for all intents and purposes there was no problem. If that's the case, then we just have to remove some of the tests.

gavinsimpson commented 9 years ago

Is the limit imposed by the API? If the code is failing bc we don't have proper objects then we should be checking objects for completeness and issuing errors/warnings if found to be lacking.

If this is is the API rate-limiting or otherwise restricting the Travis machine from pulling in data, the we need to address that. I still think we should do this anyway, but we should cache objects to run the main tests (put them in data/) and then check that given the correct data the functions run. Then we should devise simpler/shorter tests for the package unit tests that actually test the API calling code works.

We're seeing too many of these failures and often it is hard to know what is wrong; if we don't know easily the users certainly don't. Therefore trying to capture some of these and thrown useful errors would be a good thing to implement to make the package more robust now that the code is post v1 release.

SimonGoring commented 9 years ago

I'll check with Mike & Brian at PSU. That's a good point, I hadn't thought of that. I've never had a problem with rate-limiting on my computer and I've loaded lots of data. That said, I'll double check.

On Fri, Jul 24, 2015 at 11:03 AM, Gavin Simpson notifications@github.com wrote:

Is the limit imposed by the API? If the code is failing bc we don't have proper objects then we should be checking objects for completeness and issuing errors/warnings if found to be lacking.

If this is is the API rate-limiting or otherwise restricting the Travis machine from pulling in data, the we need to address that. I still think we should do this anyway, but we should cache objects to run the main tests (put them in data/) and then check that given the correct data the functions run. Then we should devise simpler/shorter tests for the package unit tests that actually test the API calling code works.

We're seeing too many of these failures and often it is hard to know what is wrong; if we don't know easily the users certainly don't. Therefore trying to capture some of these and thrown useful errors would be a good thing to implement to make the package more robust now that the code is post v1 release.

— Reply to this email directly or view it on GitHub https://github.com/ropensci/neotoma/issues/199#issuecomment-124567810.

SimonGoring commented 9 years ago

Well, the build is passing again, with 102. I'm a bit at a loss here, but I'm closing this for now because I have too many outstanding issues.