Support node.js 16 and bump node.js 12 version.

[TingluoHuang]

• As node.js v16 starts its LTS, we are supporting write actions using node.js v16.
• We also bump the node.js v12 we packaged within the runner to the latest version as part of this PR since we haven't bumped it for a long time.

https://github.com/github/c2c-actions-runtime/issues/1522

#1294

[crbudzeak]

Is there an ETA for this release? The older version of Node 12 fails Trivy scans with 14 HIGH CVE failures.

trivy_scan_sev_high.txt

[TingluoHuang]

@ethomson FYI. ☝️

[thboop]

LGTM left a thought

[bryantbiggs]

it says 2.285.0 was released 2 days ago but our runners are still showing 2.284.0 https://github.com/actions/runner/releases/tag/v2.285.0

I tried to update an action to use node16 but its failing because the runners aren't using 2.285.0 - how do we force them to use the latest release (these are not custom runners, they are the default runners)

[ljharb]

Why skip 14 entirely?? Shouldn’t actions support every LTS version of node?

[ethomson]

it says 2.285.0 was released 2 days ago but our runners are still showing 2.284.0 https://github.com/actions/runner/releases/tag/v2.285.0

Sorry for the inconvenience @bryantbiggs - 2.285.0 was released, but it takes time to get that updated across our runner fleet and against our services. We'll announce on https://github.blog/changelog/ once this is generally available. We expect this to complete on Thursday but it could be delayed (as any deployment can be).

I tried to update an action to use node16 but its failing because the runners aren't using 2.285.0 - how do we force them to use the latest release (these are not custom runners, they are the default runners)

If you're running self-hosted runners, you can feel free to download the newest version yourself and run it. But if you're using GitHub-hosted runners, you'll need to wait for our deployments.

[ethomson]

Why skip 14 entirely?? Shouldn’t actions support every LTS version of node?

We're intentionally conservative about the Node versions that we bundle in the runner application - and that you can subsequently author actions in - because this is something that we need to support even after Node.js leaves LTS. (We still support actions written as containers from the original Actions v1 before they were GA'd, before we moved to a JavaScript runtime model.) By skipping LTS lines, we're able to keep the support matrix smaller.

Our hosted runner virtual machines, of course, have all the various versions of Node.js installed (or can download them on-demand).

Are you trying to author an action and need Node.js 14 support explicitly, and neither Node.js 12 nor Node.js 16 will work?

[ljharb]

I don't have a concrete scenario at the moment, because I can't try upgrading my actions to node 16 until #1439 (comment) :-)

However, I could easily see a scenario where I'm using a compiled dependency - like node-sass (a problem i'm running into right now with storybook on react-dates, which only installs on node <= 14) - that only works on node 14, and thus I'd be screwed with the current scenario (where i can't use node 14 syntax on node 12, but i can't use node-sass on node 16).

Generally, dependencies will always work, eventually, on any node version that will become or has been LTS, but that can be a slowly moving window.

Is there a reason that it couldn't work more like setup-node, where the action can use whatever version of node the setup-node action uses?

[ethomson]

Generally, dependencies will always work, eventually, on any node version that will become or has been LTS, but that can be a slowly moving window.

Indeed. We move slowly here, too as a result. 😁

Is there a reason that it couldn't work more like setup-node, where the action can use whatever version of node the setup-node action uses?

Let me put a pin in the "more like setup-node" part of that question and come back to it. If we remove the "more like" then the question becomes "Is there a reason that it couldn't use whatever version of node the setup-node action uses", then action authors can't reliably know what runtime they're targeting. If a user ran setup-node for v12 in their workflow, then an action is also running on v12 and so they can't use top-level await (for example).

(I don't mean to make this a strawman, this is a totally reasonable approach if you're building workflows and writing your own actions for those workflows. But the actions in the marketplace are meant to be used more broadly and so actions authors need be able to write an action and give a platform requirement for running it. That way an action can specify that it needs node16 and use top-level await (for example) even if a user setup-nodes for v12.)

So the runner brings a copy of Node.js to the party so that we can ensure consistency and availability - that an actions author can always ask for Node 16 and that we can always make it available.

This is largely because we need to support an individual action across so many different environments. The GitHub Actions managed runner VMs are easy because we own them. (We can - and do - just put Node.js versions on the runners.) Self-hosted runners are the tricky part - we want to be able to run a workflow, including one with actions, one whatever the user already has, just by installing our runner. This expectation is even moreso with containers, which users typically build as small as possible and may even be taking off the shelf.

Anyway, that's the reason that we don't do every LTS today (to avoid bloating the runner). I do think that there are opportunities to make this more flexible in the future. @TingluoHuang is fixing our upgrade story so that the runner will download deltas to self-update, instead of downloading the whole package. This will help us as we're adding new Node.js versions.

Coming back to the "more like" piece that I tried to artfully dodge earlier. I'd be a lot more cautious about adding a "runs-on: node14" and making users supply that Node.js 14 runtime (meaning that your action will work on GitHub hosted runners and users would need to configure their own runners to support it). We'd need to make improvements to the runner to detect these problems and fail gracefully, but it's an idea with merit.

[ljharb]

Oh I didn't mean to suggest that the consumer had to bring a node - altho that seems useful too as an option - but more that maybe the action itself could use its own node via setup-node, so that this action doesn't require any changes in the future to install any arbitrary node version.

[argenta-quanto-zz]

looking forward to version 2.285.0 be released.

[shogo82148]

It looks that version 2.285.0 is now rolling out 🎉

• bump Node.js v16 shogo82148/actions-create-release#253
• https://github.com/shogo82148/actions-create-release/runs/4395724603?check_suite_focus=true

[pechitook]

Hey folks. Is it possible that merging this made node12 not being respected anymore by a custom action? We had a workflow with the following configuration which worked last night and today it did not

using: 'node12'
main: 'index.js'

We could check that the job would indeed run everything with node 16. Our solution was to rely on docker instead.

using: 'docker'
  image: 'docker://node:14-alpine'
  entrypoint: '.github/actions/custom-action/run.sh'

Also @ethomson to your comment about Node 12 or Node 16 being enough: It is worth mentioning Node 14 does add some interesting features unsupported in Node 12 and given Node 16 completely changes lock file implementation supporting Node 14 from a consumer perspective really makes sense.

[ethomson]

Hey folks. Is it possible that merging this made node12 not being respected anymore by a custom action? We had a workflow with the following configuration which worked last night and today it did not

We're not seeing any widespread reports of this, and we're seeing successful workflow runs that are using node12 based actions (which is most workflows, since actions/checkout is node12 based). What sort of failures are you seeing?

[pechitook]

The specific issue was that the way we passed an .npmrc file to the npm install command stopped working (need to research how/if this changed in Node 16) and we got 401s trying to fetch from a private repo. Adding --verbose to the npm command showed it was using node 16 and npm 8 which was not compliant with the node12 option we specify.

We had previous runs of this job (the last was from last night) in which the issue didn't happen. We use runs-on: ubuntu-latest on the job definition and the invoked action's yml file just have an input block and the runs block I shared above.

[ethomson]

@p4bloch Interesting. I'd love to see your workflow file and actions metadata. Are these in a public repo that you can share?

[busticated]

hey all 👋

i'm seeing odd behavior with my previously stable Node.js CI pipeline. TL;DR - i need to use node@12 and npm@6 but in some cases npm@8 is used for some reason despite explicitly running npm i npm@6 --global. given that npm@6 is the default for Node.js' v12 line, i can't figure out where npm@8 is coming from.

more details here:
actions/setup-node#376

[bryanmacfarlane]

Note that the node in your workflow (setup-node, env, etc) or the node in your environment are orthogonal and not related to the node the runner carries as a runtime to exec actions.

[busticated]

@bryanmacfarlane ok. i guess i don't understand how to ensure the correct version of npm and node are used then..? in my case, i'm running a tool which itself runs npm (see here)

[bryanmacfarlane]

Yeah, setup-node or actions/virtual-environments (the os image which changes and changes node version in your path) issue is probably the best place for the issue. running npm ... should invoke the npm that's in the PATH and not related to the vendored node in the runner to exec actions.