Runtime upgrade #259
Draft
Runtime upgrade #259
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes running the runtime non-sensitive to workingdir changes so that that can be changed through docker run commands to instruct the runtime to write elsewhere.
All of our other runtimes (except .Net and deno for now) are action-loop based. This allows us to make assumptions about all runtimes in the same way and consolidates further implementation efforts towards the go-proxy.
* SERVERLESS-1377 Make the Node.js 14 runtime prelaunchable This instructs the go-proxy to launch the new prelauncher.js script on its startup, amortizing the cost of doing so into the container bringup vs. the action initialization. The script deals with initializing the action itself making it blazingly quick especially for very simple actions that are just some lines of Javascript. * Remove redundant error
1. The Golang version we're building the proxy with is ancient. 1.18 is the most recent and known to work. 2. The Node.js patch version is unnecessarily pinned. We can update to 14.19.3.
* Add a Node.js 18 runtime This adds Node.js 18 as a runtime and is a straight copy of the Node.js 14 runtime, with the pending size improvements already applied to it. * Drop nim.js
* SERVERLESS-1563 Support ES modules as functions This changes the runner to be able to import ES modules and CommonJS modules in a backwards compatible way so that both ES modules and CommonJS modules are supported as functions. * Flip ES module detection logic around
The compile script needs python to work correctly. It's necessary for log shipping based use-cases.
* Change Node 18 Dockerfile to install packages before copying in source files. * Re-arrange npm install step in Dockerfiles for faster subsequent builds.
Comment changes and remove ancient support for nim.js. Removing nim completely from this runtime requires changing the dependency declaration in the main build for the runtime (TBD).
…imes together Add Lambda function support to main runtime variant via sig auto-detect. (#16) Re-uses our "Lambda runner" JS code that we're already using in the Lambda variant of the Node.js runtime to support Lambda function signatures in the regular runtime too. This makes the non-Lambda variant work with both OpenWhisk and Lambda function signatures. It's backwards compatible because the Lambda runner JS code still uses the env var, so customers using the Lambda variant of the Node.js runtime explicitly will have their functions continue to work. Also simplifies some error handling in the launcher.js and prelauncher.js files. It now assumes it will be able to successfully import the Lambda runner code.
) We've "merged" the Lambda and the non-Lambda runtimes with the goal of being able to benefit from Lambda's context capabilities. However, the runner does a lot of more things that don't really make sense outside of a "Lambda compatibility layer" context. Those are: 1. Forcing a Promise return for functions that have more than 1 argument. 2. Supporting a 3rd callback parameter. 3. Mangling the input event if it looks like an HTTP event constructed by the controller. 4. Supporting Lambda-specific capabilities like `callbackWaitsForEmptyEventLoop`. This backs some of the merge out again and implements context-mapping "natively" in the non-Lambda runner to make it behave like before but pass an additional context parameter.
Recently, the Node.js docker image was updated from 18.13.0 to 18.14.0 which also caused an npm upgrade from 8.19.3 to 9.3.1. The 9.x series of npm has made changes in that it stops mucking with the ownership of the installed node_modules. That's causing us trouble right now. A discussion of the matter can be found in npm/cli#5889. Downgrading npm to 8.x unwedges the issue for now.
The debian stretch repositories have been moved to the archive. To ensure we can still build from the same base image, this fixes the respective sources to pull from the archive.
This changes the sentinels to be written directly to FD1 (stdout) and FD2 (stderr) to avoid users tampering with how the sentinels get written and thus break our expectations towards how the sentinels are written. This has been an issue with customers when they used packages like log-timestamp to patch the console functions to output timestamps as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.