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

Add support for nodejs16.x runtime #318

Merged
merged 1 commit into from
May 28, 2022
Merged

Add support for nodejs16.x runtime #318

merged 1 commit into from
May 28, 2022

Conversation

ofhouse
Copy link
Member

@ofhouse ofhouse commented May 28, 2022

  • Adds support for nodejs16.x runtime
  • Increases minimum Terraform AWS provider version from 4.8 to 4.15.0

Fixes #316.
Fixes #315.

@ofhouse ofhouse added this to the v0.13.0 milestone May 28, 2022
@ofhouse ofhouse merged commit 658aa8a into v0.x May 28, 2022
@ofhouse ofhouse deleted the feat/nodejs16.x branch May 28, 2022 09:49
@timbodeit
Copy link

Hey @ofhouse,

This PR has bumped the lambda_runtime variable in /variables.tf which appeared to have been unused and was subsequently removed by you in a2134fd.

The other runtime defaults are still set to nodejs14.x:

  • modules/statics-deploy/main.tf in module "deploy_trigger"
  • modules/proxy/variables.tf in variable "lambda_default_runtime"
  • modules/lambda-worker/variables.tf in variable "runtime"
  • modules/cloudfront-proxy-config/variables.tf in variable "lambda_runtime"

It seems to me as if this PR adds support for 16.x while leaving the default at 14.x. Was this intended or should the default runtimes for v0.13 have switched to 16.x?

Would it make sense to reintroduce the root level lambda_runtime variable and wire it up the the four above mentioned runtime parameters? Or is there any of those that should be controlled individually?

@timbodeit
Copy link

Nevermind ... I seem to misunderstand the branching model.

Is there any chance you might have any additional reference regarding the branching model you're following?

What's the role of main, release, release-v0.x and v0.x branches? What's the vision regarding the v1.0 vs v0.x release tracks?

@ofhouse
Copy link
Member Author

ofhouse commented Jun 8, 2022

Hey @timbodeit,
the project is currently in a transition phase from v0.x (includes versions like v0.13) to v1.0.0.
v1.0.0 is currently in preview, so releases from the 0.x branch should be used for production work.

Current plan is to support v0.x with bugfixes and minor features until v1.0.0 becomes generally available.
v0.x and v1.0.0 are incompatible with each other since the architecture behind it is completely different in the way how deployments are made.

So the current branching situation is the following:

  • 0.x Current development version of 0.x releases
  • main Current development version of 1.0.0 release

The release branches are an internal model to reduce the files that are downloaded by Terraform.
Terraform downloads a full snapshot of the repository on terraform init.
Since we use the repository as a monorepo, we run a special task before each release that only copies the files over to the release branch that are relevant for Terraform:

  • 0.x -> release-v0.x (Contains releases like v0.13.2)
  • main -> release (Contains releases like v1.0.0)

Regarding the runtime:
The module consists of two types of Lambdas:

  1. Managed Lambdas that support the deployment workflow (e.g. modules/statics-deploy/main.tf)
    The code in these Lambdas is downloaded precompiled for a specific runtime (in this case nodejs14.x) when running terraform init (Think of it as some sort of a fixed image that is provided by us)
  2. Next.js Lambdas
    These are the Lambdas that are used for the server-side-rendering of Next.js and are created with tf-next build

The runtime of the managed Lambdas is updated when a Node.js version becomes generally available on Lambda and Lambda@Edge (for the proxy packages).
Since nodejs16.x is currently only available for Lambda but not for Lambda@Edge, the update here is deferred.

However this has no impact for your development, since what you use are the Next.js Lambdas.
This is what this PR is for, it changes the target of the Next.js Lambdas to nodejs16.x when you are running tf-next build.

Sorry for all the confusion here, will try to improve the documentation on this point 👍

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.

2 participants