Process for determining supported platforms

[Trott]

As far as I know, we don't have a formal process to determine what platforms are officially supported and what platforms are not. In this context, I'm using "supported" to mean "tested in CI".

We currently have a situation where CI has not been green for days because of the addition of AIX. AIX currently fails to build with some frequency. Hopefully that will be resolved soon, making this specific pain point go away. But I think it may be worth hammering out some larger issues:

• Who decides what platforms belong in CI?
• How is the decision made?
• Might we be able to improve the process for adding platforms to CI to reduce the disruption to CI?

/cc @nodejs/build @nodejs/ctc @nodejs/testing

[targos]

Another platform that I think was added recently to the CI is docker-alpine Linux. I'm having trouble with it because it doesn't build with current V8's ToT and I don't know :

• if it is officially supported / must always pass CI
• who to contact about it

[Starefossen]

Regarding Alpine. That was added by request from the @nodejs/docker WG. There is a high demand for a very small Node.js Docker Image based on Alpine. The Docker WG did not feel comfortable providing such an image before we knew that Node.js did in fact support the Alpine distribution.

@ncopa has been essential to getting the tests to pass on Alpine in the past (#5099 #5056).

Other related threads regarding Node.js on Alpine:

• Alpine Linux / Docker Build build#75
• Preliminary Alpine support for CI build#437
• Add an Alpine variant? docker-node#46
• Consider alpine/busybox base image docker-iojs#44

[joaocgreis]

I'm keen on the idea of allowing any platform to be supported as long as:

• there is demand for it;
• there is at least one person in the Build WG able to maintain the machines, who follows discussions there (at least those that may affect the machines or Jenkins);
• there is a support team for escalating issues when testing in the platform.

When a new platform is added, it should be properly advertised with an issue in the main repo (this one) with a mandatory @-mention to the collaborators team and reference to the support team and current support status.

Of course, CTC should have the last word about it, and be able to decide at any moment that any platform should be added or removed.

[jasnell]

There really ought to be an official list of supported platforms, perhaps maintained in the README.md. Additions to that list would be semver-minor, removals would be semver-major. I'm definitely +1 on @joaocgreis' requirements.

[Starefossen]

@jasnell I agree that supported platforms should last for an entire major version, but why would additions to that list require a semver-minor?

[retrohacker]

An update from the @nodejs/docker WG regarding Alpine (no bearing on process):

I've been experimenting with ways of shipping a minimal docker image without needing to use Alpine etc. It is looking like it is possible using debian:jessie to supply shared libraries for the nodejs binary (I have an image running locally that is down to 26MB for v4.X).

This would have the advantage of not requiring upstream to support libmusl.

[jasnell]

@Starefossen ... simply to raise the visibility of adding a new platform. There's extremely little process around a semver-minor and they can go out in current versions without any problem.

[ofrobots]

I think we should be very deliberate about which platforms are added to the 'supported' list, especially given that removing them is going to be semver major.

I think it is okay to add experimental/WIP platforms to the CI, but I think these should be very clearly marked as 'experimental'. Failing CIs end up causing a large amount of churn.

[mhdawson]

Note PR to fix the referenced AIX issue is here:, #8272. Note that until we have as many runs as we get from having the regular launches some intermittent issues like this might not surface so there might also be some churn when adding something new.

[jbergstroem]

This has been on my agenda forever :( would platform imply architecture and os combos or something else?

[Trott]

would platform imply architecture and os combos

I think yes.

[jbergstroem]

Also, toolchain; gcc vs clang - perhaps lowest glibc version supported and so on? Just adding for discussion.

[rvagg]

Proposal from the Build WG meeting this week goes something like this:

• It's entirely up to the CTC to sign off on a "supported platforms" list
• The Build WG can be used as an expert group to (a) come up with an initial proposed list and (b) occasionally advise on updates to the list or be consulted on proposed updates. If we had an active Hardware WG then they could also be in the conversation but we don't have that right now.
• It would be good to have at least 2 tiers of hosts, perhaps even 3 (names could be improved here):
  • Officially supported: test failures on these permutations should prevent a release; master and release branches should always be green on these
  • Aspirationally supported: aiming for always-green but releases shouldn't be held up and collaborators should attempt to get to green on master and release branches but excessive yak shaving to get support should not be a holdup (e.g. getting musl features working for alpine builds?)
  • Experimental: mostly would be the Build WG playing with new platforms, no requirement for collaborators to even pay attention to these if they don't care

The trick here is the technical pieces to have different levels of support. Ideally we'd be able to prevent failures on the non-official platforms from causing a red/failed build. Perhaps we can reuse the yellow/flaky stuff somehow. The Build WG has some ideas here and some TODOs for experimentation on how to make this work. The other path is to simply deal with this complexity through the new github bot that's going to be reporting all sorts of stuff to github and may even mean collaborators don't need to even touch or look at Jenkins.

[cjihrig]

This happened recently in libuv - libuv/libuv@be0e24c. It might be worth at least referencing since it could be tricky for Node to support platforms that libuv does not.

[rvagg]

Moving to nodejs/build#488 for now, will come back to ctc-agenda when we have something to report!

[jbergstroem]

There is now a draft proposal from the build group available here: https://gist.github.com/jbergstroem/8a4a5b6a602aacc96eb8a171698c324c. Comments and/or discussion lives in nodejs/build#488. The idea is to put this in front of CTC next week (week of sept 26th).