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 for a Maintained Version of NodeJS #240

Closed
eric-hemasystems opened this issue Feb 28, 2024 · 2 comments
Closed

Support for a Maintained Version of NodeJS #240

eric-hemasystems opened this issue Feb 28, 2024 · 2 comments

Comments

@eric-hemasystems
Copy link

Looks like the containers are still stuck at 16.15.0 from when they were upgraded almost 2 years ago. Seeing as Node v16 has been EOL for about 5 months now, would it be possible to update to a newer version of Node? Looks like v20 is LTS with EOL being on 2026-04-30.

Not only is there the obvious security concern, I'm also having to pin more and more packages to an old version to have something that can still run on GCP.

@MuhammetDilmac
Copy link

I agree with you. I can't update vite version because of that.

@eric-hemasystems
Copy link
Author

I'm actually going to close this. Looks like this whole repo is legacy. We recently started getting a message when deploying that says:

WARNING: ruby 3.1 and earlier versions will reach end of support on 2024-07-10 for App Engine flexible environment. After 2024-07-10, you cannot deploy new or re-deploy existing applications that use runtimes after their end of support date. We recommend that you migrate to the latest supported version of ruby.

This confused me as we were running on Ruby 3.3 (although it compiled it every time per #231). Finally looked into it more and it seems GCP has deprecated this whole process in favor of something built on buildpacks. You can find this in the docs where it says:

For version 3.2, you must include the runtime_config and operating_system settings in your app.yaml file to specify an operating system.

Evidently this is something they introduced in the last few years but since they didn't communicate it well I was completely unaware that the setup we had was legacy and soon to be no longer working.

The good news is the new buildpack stuff is better due to being both faster (it is smarter about building containers than the old setup) and using newer software. The downside is it is more complex (mitigating part of the advantage of GAE) and less flexible. For example if you need to install custom Ubuntu packages you could do so before via the runtime_config.packages config in app.yaml. That no longer works and those same docs say if you need to use custom packages you:

you will need to use a custom runtime based on this runtime to install the appropriate packages.

Doing a custom runtime means your all on your own for maintaining a dockerfile which seems like a pretty heavy price if you just need a few packages installed. The GAE docs don't really mention it but I did find you can customize the buildpack stuff. Since GAE is built on the GCP buildpacks this gives you a bit of the best of both worlds. You are still using the GCP buildpack stuff for the most part. But you have the option to install packages during the build process or for the runtime. This does bring some more complexity but still less than maintaining your own Dockerfile.

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

No branches or pull requests

2 participants