@GWicke We already support alternative node versions in docker build script. See T114399 (resolved by this PR), so the easiest way to resolve this task is to add node version config to RESTBase config and other services configs as we switch them to 4.2

In T123237#1924514, @Pchelolo wrote:

We already support alternative node versions in docker build script.

+1. While the service-runner's docker script uses the version provided by nvm, I'd say this leaves enough flexibility so that service-runner isn't tied to our apt repo.

My concern with using the nvm version is that it opens up some chance of binary dependency disagreements between the build environment & what we run in production. Building binary dependencies against the exact node & other library versions as used in production avoids this risk.

Given the relatively small effort involved, I think creating a WMF Jessie image is worth it. It should also be useful for CI and mediawiki-containers. We could make that the default target used by service-runner, with upstream jessie and ubuntu still supported if desired.

In T123237#1924848, @GWicke wrote:

My concern with using the nvm version is that it opens up some chance of binary dependency disagreements between the build environment & what we run in production. Building binary dependencies against the exact node & other library versions as used in production avoids this risk.

4.2.0 is marked as stable in nvm so I doubt that this will present a real issue in practice.

4.2.0 is marked as stable in nvm so I doubt that this will present a real issue in practice.

I agree that it's unlikely, but given the limited effort involved & the high stakes I think it's worth ruling out any incompatibilities.

There's a 'docker-registry.tools.wmflabs.org/wikimedia-jessie' you can pull. I think at some point @Joe might be working on having this be served from production.

(No guarantees are made about the stability of that docker image, but I'll notify you in case we change it)

@yuvipanda: Awesome, thanks!