Add Node 18 to current image variants.

[kimmoahokas]

The LTS support for Node 16 is ending 2023-09-11. Please add support for the next LTS release, Node 18 as soon as possible. We need to start migrating our workloads soon, but can't really do that without CodeBuild support.

[JoeFirebaugh]

For what it's worth, this is how our team uses NodeJS 18 in our builds.

[kimmoahokas]

Yes, I'm aware of that and have been using it as well in some less-critical builds. But in the longer run I'm rather hesitant to use a feature that is not documented and officially supported.

[subinataws]

Node 18 should be supported on Ubuntu based image in a couple of weeks from now. Amazon Linux image will be updated to AL2023 base and support Node 18 by mid-May.

[Dylan-AWS]

Added node18 support to Ubuntu 7.0 #621

[mfittko]

Can we also get this for the AMAZON_LINUX2 based images? What about AARCH/ARM? It would be really odd if we couldn't use codebuild for our project since we're on graviton2 (ARM), ruby 3.1 and node LTS (18)...

(EDIT)
Just saw that AARCH even got deprecated. Don't you want the users to be able to build their current projects on ARM any more? That means we cannot deploy our Fargate workloads on ARM unless we want to live with cross platform builds (bad performance, possible bug vector)

[subinataws]

Arm images will get an update next week. AL2023 updates by mid-May.

[mfittko]

Arm images will get an update next week. AL2023 updates by mid-May.

Sounds great 👍 Will the ARM images also be not deprecated then? I just saw that these images are like 3gb so it's really not an option for us if they won't be cached.

[subinataws]

Older images will need to be dropped from cache, so as to make space for the newer versions. Customers will get heads up before they are dropped from cache. All the supported versions will still be cached on the build server's AMI, which is typically the latest version (say, n) and the just prior version (n-1).

We will look into re-introducing per language runtimes to avoid long provisioning times when images are no longer cached. Offering multiple version of runtimes on the same image makes these images quite big unfortunately.

[mfittko]

yeah, thanks for the insights @subinataws . to me, as building long time CircleCI customer, it is also a bit odd, not to be able to build your own image on top of the base. so why not just provide barebone base images like https://github.com/CircleCI-Public/cimg-base where we could add whatever lib or binary we would need to, so basically only our additional layers would not be cached on the runners if we'd provide these on ECR for ourselves?

[subinataws]

@mfittko - Thanks for bringing that up. We certainly can host the CodeBuild images that are based on Amazon Linux (unfortunately not for Ubuntu) on https://gallery.ecr.aws/codebuild. We have the x86 version there and I see that we never published the Arm ones. We'll get that published on there as well. You can derive from those public images to extend your custom images.

[mfittko]

That would be super awesome. I just hope that given the huge size of these images, that also the layers of these ECR hosted images will be cached on the build hosts? Are the build hosts picked based on the architecture of the image or will they all be ran (emulated on an AMD64 host)?

(Sorry for getting off topic, btw)

[subinataws]

Build instances are picked based on the architecture selected in the CodeBuild project.

[vitorhnn]

Any update on the new ARM images? This is blocking us from upgrading to Node 18 for our builds.