Fix testing suites outside of the current directory tree with Go 1.8 and test against Go 1.8 in CI

[goonzoid]

This was a fun one to figure out! 🤡

Ginkgo's own integration suite was failing when using go 1.8. It turns out that a change in Go 1.8 means that relative import paths outside of the current directory tree can't begin with ./.

Fix this by adding some logic to detect relative paths outside of the current directory tree, and then took the liberty of adding Go 1.8 to .travis.yml.

[goonzoid]

And of course it fails on CI 😢

I'll take a closer look tomorrow or later this week and see if I can figure out what's different there compared to my local machine (may well be an OS X vs Linux thing I suppose).

[goonzoid]

So, turns out the integration suite is significantly slower using Go 1.8 ☹️

I bumped the default Eventually timeout in the integration suite to 30s (from 15s) and it's green now. Not sure if that's the right thing, or if it would be better to dig in to the perf issues. If that's preferred, I can back out the timeout change and the commit that adds Go 1.8 testing to CI and that can be handled separately.

Let me know! 🍔

[onsi]

Hmm. That's concerning. I think we should dig into the perf issues but that's almost certainly a ton of scope creep for you Will. I can try to find some time to do this but if you're up for taking a first whack at it I'd appreciate it. TBH go compilations have seemed to get slower and slower since 1.5... that may be more anecdotal than fact-based but i suspect something like that is to blame here. One quick thing to try: can you drop the `-i` arg on this line: https://github.com/onsi/ginkgo/blob/master/ginkgo/testrunner/test_runner.go#L61 and try the tests again? I've never fully understood how `-i` works and whether it helps or hinders. See this issue #305 for what might be relevant context is the `-i` thing helps/hinders.

…

On Tue, Mar 21, 2017 at 2:50 PM, Will Pragnell ***@***.***> wrote: So, turns out the integration suite is significantly slower using Go 1.8 ☹️ I bumped the default Eventually timeout in the integration suite to 30s (from 15s) and it's green now. Not sure if that's the right thing, or if it would be better to dig in to the perf issues. If that's preferred, I can back out the timeout change and the commit that adds Go 1.8 testing to CI and that can be handled separately. Let me know! 🍔 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#337 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAiElseOkbydpD6RUznS9ILd5GD_PTpVks5roEY5gaJpZM4MjEFE> .

[goonzoid]

I've reverted the timeout increase and pushed a change without the -i flag just to see what happens on CI. I'm getting confusing and inconsistent results on my dev machine, but I'd like to dig in to it more in a day or two when I have some more time.

[goonzoid]

@onsi looks like you've already figured this out on master, so I'll close this.