Promote official node images for yarn and npm users

[imjasonh]

I would like to propose that we deprecate and stop building the npm and yarn builders, and instead recommend that users use the official node image from Dockerhub.

This image gets regular updates from the official Node maintainers, and new versions of node are immediately available as builder images.

The only downside (AFAIK) is that the images don't specify an entrypoint, so instead of:

steps:
- name: gcr.io/cloud-builders/npm
  args: ['version']

users would have to write:

steps:
- name: node
  args: ['npm', 'version']

However, the node image includes both yarn and npm, and is updated and tagged with the version of node, so it's easy to specify in your build:

steps:
- name: node:6.14.3
  args: ['npm', 'version']
- name: node:10.8.0
  args: ['npm', 'version']
- name: node:10.8.0
  args: ['yarn', 'version']

I propose we recommend that users should use the official node image, include a deprecation warning in gcr.io/cloud-builders/npm and /yarn, and eventually break those images to force stragglers to use the official node image.

We would cache popular versions of the node builder on worker VMs, just as we do for npm and yarn builders today.

@palmerj3 @victorandree As recent contributors to the npm and yarn builders, I'm especially interested in your feedback.

P.S., if this work proves successful, we could possibly also migrate users of dotnet, mvn, gradle, etc., to official images which receive updates more quickly.

[victorandree]

I think this is a good idea!

It should make it easier to untangle npm from node releases for people who are e.g. stuck on node 8 but want to use a more recent version of npm (as I wanted to do in #263 and @nakleiderer recently wanted to). They can just add the extra RUN npm install -g npm layer to their images but still benefit from having the base image cached. Neat!

Personally, I would be very happy if this somehow meant that popular node images were immediately available as base images when doing Docker builds! I.e. that the docker cloud builder could share image cache, somehow. But maybe that's unrelated and too complicated.

[imjasonh]

This change wouldn't cache popular node packages, just the layers of the official node image, sorry.

[victorandree]

I don't expect node packages to be cached!

But I've noticed that when we use the docker builder to build Docker node images, the FROM node:10.X line in the Dockerfile typically requires pulling the image. That takes a couple of seconds. However, when we build a utility Docker image that uses FROM gcr.io/cloud-builders/gcloud, it doesn't have to be pulled. When that utility image is later used as a build step, most of its layers "Already exists [sic]" so it's all very fast.

Bottom line, I think it would be a good idea to do this for npm, especially if it has the added benefit of making node base images cached for Docker builds.

[imjasonh]

Oh sorry I misunderstood your comment. Yeah, caching node and some popular versioned tags should make them faster to build images on top of.

[palmerj3]

I would rather support the yarn and npm cloud builders here. I'm happy to do it.

The reason is that the interface should be the same. The node endpoints not setting the entrypoint to npm means it's a node cloud builder not a npm/yarn one.

Back to the purpose of cloud builders which is a single-purpose command.

So I'm in favor of them staying here and being maintained.

[eddiemonge]

Using the official node means npx would also be supported

[naseemkullah]

SGTM, especially provided:

We would cache popular versions of the node builder on worker VMs, just as we do for npm and yarn builders today.

[bendory]

Caching is an implementation details of the hosted service -- but to be clear, the expected result of this deprecation is that users of the hosted service will not experience any significant changes in build times or startup latencies.

[naseemkullah]

SGTM, especially provided:

the expected result of this deprecation is that users of the hosted service will not experience any significant changes in build times or startup latencies.