Google-cloud-node: Run docs, samples, system, lint tests on node 10

[JustinBeckwith]

Our kokoro config is currently set up to run all these tests on node.js 8. That's going EOL by the EOY, and it's slower than 10. Let's upgrade!

[jkwlui]

It's time to move on :)

[stephenplusplus]

Sorry I missed this earlier, but I wanted to reopen to discuss an alternative approach. Should we think about running system tests across all of the supported versions? If that's unfeasible, I would think we should lean towards the smallest supported version, as that's the place where we're likely to run into compatibility issues.

An example case: https://github.com/googleapis/nodejs-storage/pull/619. Upgrading to gcs-resumable-upload@1 is incompatible with Node 8. Our previous system tests correctly caught this and failed. We upgraded to Node 10, and then it passed, and we merged.

[JustinBeckwith]

This was rotten timing and luck for a change, huh? A few thoughts here.

Running system/sample tests on a matrix
These tend to be pretty resource intensive tests. We're creating stuff, deleting, doing all sorts of reads.. We already run into quota trouble a fair bit, and we fight backend flakes from time to time. I'm worried that this isn't the place for a matrix. Tbh - this is what I count on the unit tests for.

Defaulting to the lower major LTS version
I feel like we're picking our poison here. Even money there's a bug that only appears in 10 when it's something this subtle. I'd prefer to stay on 10 if possible, cause it's faster and lets us use more advanced features in our system and sample tests. Also, probably matches what most people are using since we're counting down the months until 8 deprecation.

TL;DR - would it be at all possible to capture this case in a unit test?

[stephenplusplus]

So far, I'm still investigating that particular issue. But the error seems network-connection related, so it could indicate a change in an upstream transport mechanism/dependency, so system tests are appropriate for this type of test. I think we actually have a duplicate test where we simulate the network, and we're getting green ✅s. But, again, I don't know for sure what it is yet, so it could very well turn out to be an easy unit test fix.

I'd prefer to stay on 10 if possible, cause it's faster and lets us use more advanced features in our system and sample tests.

I agree, although that's not why we have system tests. We should just be concerned with not breaking user code. Our development experience shouldn't de-prioritize user experience.

Factually speaking, I would consider the matrix approach mandatory for ensuring compatibility. Without it, we don't actually know if we're green on all of our supported versions. It sounds like a matter of practicality that we are limited to testing just one Node version*, so sticking with the most likely to cause problems makes sense to me, as opposed to the new, fun, and exciting Node versions :)

* Is it worth having a discussion about going back to the matrix approach? Maybe even a special, one-time run that only happens before a release?

[stephenplusplus]

The same test turned out to uncover yet another difference, where Node 6 and 8 fail for different reasons. More info on that: https://github.com/googleapis/gcs-resumable-upload/issues/191

[JustinBeckwith]

So I'm a little confused :) Also cc @bcoe because this is a really interesting conversation on a variety of fronts :)

Is it worth having a discussion about going back to the matrix approach? Maybe even a special, one-time run that only happens before a release?

Were we ever running system and sample tests in a matrix?

[bcoe]

my two cents; given the exciting work happening in Node.js and V8, I think it's reasonable to drop library versions once they're (EOL)[https://github.com/nodejs/Release]. The Node.js community as a whole seems to be adopting this approach more and more, and it's meant that the exciting improvements in the JavaScript platform benefit the community in a reasonable timeframe.

I used to be much more conservative with yargs and nyc (I spent a lot of time trying to support all the way back to 0.10) ... I reached a point where I had a reversal on this, partially because my own users were advocating the upgrades.

As for a testing matrix, I definitely think it's valuable to test on all non-EOL versions of Node.js; Node.js itself will sometimes introduce regressions, and having tests run on a few versions can help differentiate between your own bugs, and the platform's bugs.

[bcoe]

\o/ this is now being done.