Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 3 commits into from
Nov 18, 2021

Conversation

TingluoHuang
Copy link
Member

@TingluoHuang TingluoHuang commented Oct 27, 2021

  • 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

@TingluoHuang TingluoHuang requested a review from a team as a code owner October 27, 2021 17:15
@crbudzeak
Copy link

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
Copy link
Member Author

@ethomson FYI. ☝️

Copy link
Collaborator

@thboop thboop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM left a thought

@bryantbiggs
Copy link

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
Copy link

ljharb commented Dec 1, 2021

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

chris-araman added a commit to mxcl/xcodebuild that referenced this pull request Dec 1, 2021
avocadowastaken added a commit to avocadowastaken/rapidbundle that referenced this pull request Dec 1, 2021
@ethomson
Copy link
Contributor

ethomson commented Dec 1, 2021

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
Copy link
Contributor

ethomson commented Dec 1, 2021

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
Copy link

ljharb commented Dec 1, 2021

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
Copy link
Contributor

ethomson commented Dec 1, 2021

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
Copy link

ljharb commented Dec 1, 2021

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
Copy link

argenta-quanto-zz commented Dec 2, 2021

looking forward to version 2.285.0 be released.

@shogo82148
Copy link

@pechitook
Copy link

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
Copy link
Contributor

ethomson commented Dec 2, 2021

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

@busticated
Copy link

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
Copy link
Member

bryanmacfarlane commented Dec 8, 2021

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
Copy link

busticated commented Dec 8, 2021

@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
Copy link
Member

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.

achingbrain added a commit to ipfs/aegir that referenced this pull request Dec 13, 2021
node 16 is now supported in gh actions.

Ref: actions/runner#1439
KengoTODA added a commit to KengoTODA/readthedocs-action that referenced this pull request Dec 21, 2021
KengoTODA added a commit to KengoTODA/readthedocs-action that referenced this pull request Dec 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.