Add Browserstack automated testing

[ZachTRice]

@localjo mentioned automated browserstack testing in conversation. I'm making a ticket to look at getting this integrated at some point. Might be something to integrate when we transition away from busterjs #96

Nightwatch, Bamboo and Travis CI are supported.

https://www.browserstack.com/automate/nightwatch
https://www.browserstack.com/automate/bamboo
https://www.browserstack.com/automate/travisci

[Benjaki2]

Running Browserstack with travis/bamboo seems like it would require a lot of overhead at this time as we need the code to be served to examine it with selenium. However, setting it up locally seems really feasible and useful.

[localjo]

@rboller That issue with SEVERE:http://localhost:3000/ - Redirect from 'http://gibs-a.earthdata.nasa.gov/wmts/...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. is holding this up. Who can I talk to to get it resolved?

[rboller]

@localjo see here for some background:
https://bugs.earthdata.nasa.gov/browse/GIBS-2199

I'll send a message to introduce you to the POC for this.

[ZachTRice]

Seems like what is needed is a Cross Origin Request with preflight
According to this stackexchange answer, "Supporting redirects to requests that require a preflight is very recent change to Fetch (which defines CORS)." August 4th, 2016

According to a post here: whatwg/fetch#204, Edge and Webkit support this but Gecko (FireFox) does not as per this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1346749)

[ZachTRice]

See this post: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests_and_redirects for detailed information about all of the above and some possible work arounds

I added this info to https://bugs.earthdata.nasa.gov/browse/GIBS-2199

[localjo]

It looks like we might be able to solve this problem by adding the protocol to the source URLs; https://github.com/nasa-gibs/worldview-options-eosdis/blob/master/release/config/wv.json/sources.json

Basically, I think we should be using https:// instead of just //. That way we avoid the initial redirect. Those // protocols look like they've been in there for years, but I don't think that's necessary. Going to test out replacing them with https://. Does anyone have any reason why we shouldn't do that? @rboller