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.