CI: test on Node 16, switch to newer cimg images

[glasser]

Node 16.0.0 is now released; we should run CI against it.

The older circleci/node Docker images we use in the Apollo OSS orb do not yet
have 16.0.0. It seems reasonable to switch over to the "non legacy" cimg/node
Docker images anyway. Those images don't have "major version" tags like 16, just
tags like 16.0.0 and 16.0. So let's switch over to specifying images directly
in config.yml rather than via our orb, and let Renovate update it. See
https://github.com/renovatebot/renovate/blob/92aab2b30f5c0d811056a1574354e97057c42732/lib/manager/circleci/extract.ts#L49
for what Renovate is looking for.

This PR does not convert to using npm v7 (and its new package-lock.json format);
we should do that soon, perhaps on release-3.x.

[glasser]

@abernix Curious about your thought on the approach here.

Note that the hapi tests fail. I think that is because only the very latest hapi release supports Node 16.

Not clear on whether a hapi upgrade can actually work in the AS2 context (see eg #3273); I see you have made it up to "@hapi/hapi": "19.2.0" on release-3.0 (this may require 20.1.2). So we may be able to say "Apollo Server 2 supports Node 16 except for apollo-server-hapi" or something.

[abernix]

@glasser I have already evaluated things like @hapi support on 2.x and opted to put it in the easier to reason about 3.x branch where it was just naturally compatible with the other upgrades. We've historically done some exceptional things for certain frameworks to allow the tests to pass (e.g., see any references to NODE_MAJOR_VERSION in our tests.

I wasn't thinking we'd introduce Node.js 16 to the 2.x range; I'd be pretty comfortable with us only introducing Node.js 16 testing (exclusively) on the release-3.0 branch as a motivator/incentivization for folks who want to live on the bleeding edge and use the alpha releases. Node.js 16 doesn't go LTS until October. You're picking up that branch pretty soon, so perhaps it's just a good time to start looking in that direction (only)?

[glasser]

Not trying on 2 sounds fair. I'm glad to see the only problem is in one package due to its main dep though.

Thoughts on how the cimg change is executed?

[abernix]

@glasser The executor change to docker.image seems reasonable, but note that I think it's fraught with one very real thing with regards to how Renovation would work. See my apollographql/federation#713 on federation which has a commit (and comment) explaining my thoughts there. See if that resonates with you.

(Though also, if that PR gets approved, I'm happy to apply the changes here myself.)

[glasser]

@abernix I've rebased this onto release-3.0 (which has the Hapi upgrade) and it passes!

Note that baseBranches on main in this repo does not contain release-3.0 so for better or for worse Renovate isn't running on release-3.0, so while this means Renovate won't help us keep these up to date on the branch, it also won't clobber them. That's OK for now I think.

(We could add release-3.0 to baseBranches but it'll still use the main config which seems bad. I think the best way to go here is rapidly get to the point where main is 3.x and 2.x is on its own branch and probably doesn't get renovated.)

[glasser]

Thoughts on if we should bump this to the 14 or 16 job?

[abernix]

I had written out a longer comment but somehow lost it. Let's wait and ticket this for follow-up in a few weeks? (Feel free to assign to me). Basically, this persist_to_workspace thing propagates things to the Tarballs and Publishing steps: https://github.com/apollographql/CircleCI-Orbs/blob/main/src/oss-ci-cd-tooling/orb.yml#L319-L346

[glasser]

still curious about this fwiw, but merging @abernix

[abernix]

LGTM. I think you said you expected a PR to renovate this, but also maybe experimented or understood better than I currently do that it would be constrained by something. We have had Renovate target multiple base Branches in the past. Happy to look at that.

[glasser]

@abernix My understanding is

• you can configure renovate to target multiple base branches
• but the configuration used is always the default-branch configuration
• and currently we aren't targetting release-3.0 from that
• and even if we were, the delta between release-3.0 and main's renovate configs is pretty high

My theory is that we do not have to wait for 3.0.0 to be released to either (a) merge release-3.0 into main and make a different branch for 2 or (b) make release-3.0 be the "default branch", perhaps. (Or that we'll get to 3.0.0 soon enough anyway.)