Move nodejs/readable-stream CI from Travis to Jenkins

[mcollina]

Hey folks, do you think it might be possible to do this? What would it require from our part?
At this point we are evaluating for options, as we can't get a full CI run go green because of our current infrastructure.

Our current Travis setup is quite articulated: https://github.com/nodejs/readable-stream/blob/master/.travis.yml. And we would still need #655.

cc @nodejs/streams @addaleax

[yoshuawuyts]

This is mostly because of the mobile builds right? E.g. the tunnel to SauceLabs fails. If that's the case I'm not sure moving off Travis is as much of a benefit as investing in a more reliable tunnel.

…

On Mon, Mar 20, 2017, 10:39 Matteo Collina ***@***.***> wrote: Hey folks, do you think it might be possible to do this? What would it require from our part? At this point we are evaluating for options, as we can't get a full CI run go green because of our current infrastructure. Our current Travis setup is quite articulated: https://github.com/nodejs/readable-stream/blob/master/.travis.yml. And we would still need #655 <#655>. cc @nodejs/streams <https://github.com/orgs/nodejs/teams/streams> @addaleax <https://github.com/addaleax> — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#657>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWlemRA73tBWWx2ktorzhm2hTnz2q7cks5rnklegaJpZM4MiMb5> .

[mcollina]

@yoshuawuyts There is also the fact that we are unable to trigger/manage the Travis integration, because of the lacking permissions in GitHub OAuth. At this point, we can't even restart a single job that failed.

I would like to know how much effort is needed for this, and then we can make our call.

[yoshuawuyts]

Ah yeah, super fair.

…

On Mon, Mar 20, 2017 at 11:15 AM Matteo Collina ***@***.***> wrote: @yoshuawuyts <https://github.com/yoshuawuyts> There is also the fact that we are unable to trigger/manage the Travis integration, because of the lacking permissions in GitHub OAuth. At this point, we can't even restart a single job that failed. I would like to know how much effort is needed for this, and then we can make our call. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#657 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWlekHjQeiEe9Z1wAvVdtlu8x-CFGyqks5rnlHKgaJpZM4MiMb5> .

[gibfahn]

Related to: nodejs/readable-stream#265

There is now documentation for the process of adding new job types to the CI. @mhdawson has been handling it for other projects so far (currently citgm, node-report, and node-inspect).

Basic answer is that we have a reasonably good process in place now (covered in that document). We'd set up a team called streams-admins (or readable-stream-admins, whichever you'd like). Then we'd create jobs in ci.nodejs.org and give that team access.

There are currently two types of jobs, streams-continuous-integration would just pull a tar from nodejs.org (for when you're testing a change to readable-stream). Then there'd be a streams-smoker job (for when you're testing that a change to Node doesn't break readable-stream). If this doesn't work we can always do something different, but not rebuilding node every time means a lot less stress on the CI (and much quicker CI runs).

@phillipj is working on triggering CI runs with the GitHub bot through a comment by a collaborator for that repo in nodejs/github-bot#128, and also on having the job status reporting (i.e. what we have in node core).

The only thing I don't think we'll get that Travis has is automatically running CI on PRs (for obvious reasons). However we can run on all the platforms that Node supports, which is a big plus.

[gibfahn]

@mcollina and to answer your question, it's not very much effort.

[mcollina]

@gibfahn do you think it would be hard to have a localtunnel instance running somewhere as well? #655

Or maybe the servers have a public reacheable IP address, so there is no issue?

[mcollina]

@gibfahn how would you setup those browsers runs that currently go to SauceLabs via localtunnel? As separate environments?

We are happy to pull Node.js, we just need to test this on all the Node.js versions we currently support, meaning 0.8, 0.10, 0.12, 1, 2, 3, 4, 5, 6, 7 (and soon 8). We do not care too much about multiple-platform at this point, as the source code is all JS.

readable-stream is a module on NPM (probably the most downloaded), so we need to test on what's released, so no building core stuff.

This seems quite different from what you proposed.

[gibfahn]

We are happy to pull Node.js, we just need to test this on all the Node.js versions we currently support, meaning 0.8, 0.10, 0.12, 1, 2, 3, 4, 5, 6, 7 (and soon 8). We do not care too much about multiple-platform at this point, as the source code is all JS.

readable-stream is a module on NPM (probably the most downloaded), so we need to test on what's released, so no building core stuff.

This seems quite different from what you proposed.

Yeah, that's what I meant by streams-continuous-integration, pull a tarball from https://nodejs.org/dist/ and run your tests on it. See for example the equivalent for node-report. Different how?

how would you setup those browsers runs that currently go to SauceLabs via localtunnel? As separate environments?

No idea, it's quite possible that your tests are doing something unusual that we'd need to make special arrangements for, could you give more details? cc/ @jbergstroem

[gibfahn]

You'd also set up a pipeline that runs the same job with 0.8, 0.10, 0.12, 1, 2, 3, 4, 5, 6, 7 as parameters, so you could just kick that off.

[mcollina]

Yeah, that's what I meant by streams-continuous-integration, pull a tarball from https://nodejs.org/dist/ and run your tests on it. See for example the equivalent for node-report. Different how?

I didn't understood :D.

Part of our current CI test suite opens up a server, exposed that to the world via localtunnel, then it has saucelabs connect there with various browsers, and that is published. This is not really working well for us on the localtunnel dependency.