How can a project qualify for access to the build infrastructure?

[rvagg]

This has come up a few times already and I see a few different categories of projects, although there are very blurry lines between these:

• Projects that are within the nodejs org and are therefore "owned" (?) by the Node.js Foundation and are within the scope of what the Build WG works on
• Projects that are outside of that scope but have some heightened level of importance to the Node.js ecosystem, examples of this might be npm, libuv, express, serialport
• Projects that are further out in in the npm ecosystem

node-gyp is spinning up to use our infra for testing but it's clearly within our org and scope of work so can be considered in a similar way to core.

We also do libuv but I think we can safely count libuv as a Node.js Foundation project since it's in our "incubator" thingo.

Express is there too but its future is less clear but if it wanted to use our infra to run tests then how would we handle that?

We have a job in Jenkins for serialport but I don't know if it's ever been used and I think the hardware for that was dedicated for that purpose. But serialport has no formal relationship with the Foundation.

Now we have @indutny questioning whether we can run llnode in our infra so it can support more than just Linux and OSX (which are easier to test for many people than Windows). https://github.com/indutny/llnode/issues/17#issuecomment-232111936, but we have no formal relationship with llnode except via @indutny who is obviously near the heart of our work and it's possible that llnode could become an important piece of diagnostic tooling. But likewise there are potentially a lot of other interesting ecosystem tools that could fit into a similar category. What about https://github.com/davidmarkclements/0x, who's author is active in some of our working groups and may be considered by some to be a useful diagnostic tool? There's plenty more in that category.

So the question here is what line we draw when we have requests like llnode come in? While I'd love to be really open with our hardware I see two primary problems:

1. Security, for all the same reasons we are so careful about who and what gets to run on / use our CI machines.
2. Intention of donors, in that those donating our hardware may have certain expectations about what its being used for, perhaps it's not a big deal if we are simply using up extra capacity but that may become difficult to justify as we start to push limits or start to need additional hardware to ensure greater security/isolation.

[mhdawson]

From my perspective there are advantages to sharing our infra in that its going to be hard for smaller projects to build the breadth of platform support that we now cover and for things that are important for Node.js having the testing across the platforms is important.

As rod points out it comes down to how to draw the line. On idea I've not fully thought through is if another jenkins instance to run tests for "non-core" but important projects might help address the concerns over security and donor intentions. Donors could indicate if they want their contributions limited to the "core" jenkins or not.

The downside is of course that we likely end up with less efficient use of resources since we can't share machines across the two.

[MylesBorins]

I had a conversation with @ljharb about using our infra for nvm... specifically to be able to test on all supported architectures. I think this is a very valuable service to offer to key projects in the ecosystem

[jbergstroem]

From a budget perspective we have a bit of wiggle room for disposable vm's. I reckon we could fit 5 2G 2cpu 40G machines without interfering with our own agenda.

[williamkapke]

Any hardware I've donated can be used in any way the build WG sees fit. I have no 'hopes' for it used in any particular way ;)

[reconbot]

I maintain serialport, it's founded by Chris Williams. Bocoup (my company) sponsors me, and a bunch embedded hardware we use for testing as part of my Web Connected Devices department. Our involvement in open source foundations is pretty common.

The test matrix we have is pretty large and I'm looking to grow it even further using docker images to emulate the hardware. I'd like to leverage our large collection of linux based single board computers we have that run other architectures (arm v5-9, mipsel, etc). We also have a weird requirement to have a serial device hooked up for integration tests (currently using an Arduino Uno). And recently (a few days ago) I was informed we now have a windows machine part of this infrastructure with an uno running nightly tests.

This summary is to say we have a good cross section of alternative hardware we can add to the Jenkins fleet and take operational responsibility for. I take testing very seriously for the serialport project and would happily explore joining the foundation to keep things maintainable and above board.

[rvagg]

As per discussion just now in Build WG meeting, we need to add words somewhere in a PR to outline a policy and get agreement from the TSC. Proposal that was just workshopped is:

Projects qualify for use of the build infrastructure if:

• They fall within the scope of responsibility under the TSC—which includes the CTC and all of the activity in the nodejs org and some related projects like libuv
• Or the TSC, or CTC and the Build WG agree that an externally managed project should have access in some form—an example of this right now is V8, which isn't managed by the org in any way but the CTC wanted to be able to run in our infra. Another example might be nvm, which may or may not end up under TSC in some form but the TSC and Build WG may agree that the trust relationships are adequate to allow for it to access our infra in a certain way (details of how that would technically work would have to be figured out).

And of course, any project would need to be able to run on our infra, there's no implicit assumption here that it's even possible or that personnel can be allocated to do the work required.

[jbergstroem]

We suggested removing this from the wg-agenda at last meeting; doing so.

[Trott]

This is a very stale issue at this point. Should it be closed?