travis notifications? Who's getting them?

[SimonGoring]

Hi all, now that I'm figuring out the travis stuff a bit better I notice that someone's got integration with slack. I was going to add my own token as well, but just wanted to check to see who else is linked to it.

@karthik @sckott @gavinsimpson ?

[gavinsimpson]

I believe this is an ropensci thing.

[sckott]

@SimonGoring yes, commits/issues on this repo go to our slack, as well as travis build reports - i imagine you can add a second notification to go to your slack if you have one

[SimonGoring]

Okay, I did and it seemed to work, but I just got a failure notification from Travis on a build that passed earlier. Did you get the same one?

On Thu, Jul 23, 2015 at 10:55 AM, Scott Chamberlain < notifications@github.com> wrote:

@SimonGoring https://github.com/SimonGoring yes, commits/issues on this repo go to our slack, as well as travis build reports - i imagine you can add a second notification to go to your slack if you have one

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

[sckott]

the last travis notification in our slack is from yesterday from this build https://travis-ci.org/ropensci/neotoma/builds/72153289

[gavinsimpson]

The travis build is failing for R code reasons. Quite why lapply(aa,[[, "dataset"] should throw an error unless the objects in aa might not have a "dataset" for some some reason is where the problem lies. It might be worth considering adding consistency checks on objects, so that we can throw proper, clear errors if the API returns something we weren't expecting or we missed patching up the object(s) in some cases.

[gavinsimpson]

This of course could be a transient issue due to the website or web API being down or acting funky mid-test of course. But we should try to capture those issues too if we can replicate them at all? Probably easier said than done...

[SimonGoring]

The weird thing to me is that this exact same build (#99) passed yesterday at 3:46pm, and is failing now. it makes me think it's a neotoma API side problem.

On Thu, Jul 23, 2015 at 11:17 AM, Gavin Simpson notifications@github.com wrote:

The travis build is failing for R code reasons. Quite why lapply(aa,[[, "dataset"] should throw an error unless the objects in aa might not have a "dataset" for some some reason is where the problem lies. It might be worth considering adding consistency checks on objects, so that we can throw proper, clear errors if the API returns something we weren't expecting or we missed patching up the object(s) in some cases.

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

[gavinsimpson]

Yes - but indicates we could do better identifying when the API has failed to return something we expected it to do.

[sckott]

we could do better identifying when the API has failed to return something we expected it to do

Is there any unit testing for the API itself? Or is the testing from this R pkg?

[SimonGoring]

Yes, the first set of tests, so it's not that that's causing the bug. I'll mess with it later today to see if I can figure out what it is. A required package update possibly (overnight?)?

On Thu, Jul 23, 2015 at 11:26 AM, Scott Chamberlain < notifications@github.com> wrote:

we could do better identifying when the API has failed to return something we expected it to do

Is there any unit testing for the API itself? Or is the testing from this R pkg?

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

[SimonGoring]

I'm closing this issue ('who's getting notifications') and moving the Travis failures over to issue #199.