circleci-public/cimg-node

The CircleCI Node.js Docker Convenience Image.

CircleCI Convenience Images => Node.js

A Continous Integration focused Node.js Docker image built to run on CircleCI

This image is designed to supercede the legacy CircleCI Node.js image, circleci/node.

cimg/node is a Docker image created by CircleCI with continuous integration builds in mind. Each tag contains a version of Node.js, npm, yarn v1, and any binaries and tools that are required for builds to complete successfully in a CircleCI environment.

Support Policy

The CircleCI Docker Convenience Image support policy can be found on the CircleCI docs site. This policy outlines the release, update, and deprecation policy for CircleCI Docker Convenience Images.

Table of Contents

• Getting Started
• How This Image Works
• Development
• Contributing
• Additional Resources
• License

Getting Started

This image can be used with the CircleCI docker executor. For example:

jobs:
  build:
    docker:
      - image: cimg/node:15.0.1
    steps:
      - checkout
      - run: node --version

In the above example, the CircleCI Node.js Docker image is used for the primary container. More specifically, the tag 15.0.1 is used meaning the version of Node.js will be Node.js v15.0.1. You can now use Node.js within the steps for this job.

How This Image Works

This image contains the Node.js programming language and its package managers. This includes npm and yarn.

There was a recent change reimplmenting vanilla node after briefly using nvm. While it is implied and recommended to not use sudo when possible, you will now need it when installing packages globally.

Variants

Variant images typically contain the same base software, but with a few additional modifications.

Browsers

The browsers variant is the same Node.js image but with Java, Selenium, and browser dependencies pre-installed via apt. The browsers variant can be used by appending -browser to the end of an existing cimg/node tag. The browsers variant is designed to work in conjunction with the CircleCI Browser Tools orb. You can use the orb to install a version of Google Chrome and/or Firefox into your build. The image contains all of the supporting tools needed to use both the browser and its driver.

orbs:
  browser-tools: circleci/[email protected]
jobs:
  build:
    docker:
      - image: cimg/node:15.0.1-browsers
    steps:
      - browser-tools/install-browser-tools
      - checkout
      - run: |
          node --version
          java --version
          google-chrome --version

Tagging Scheme

This image has the following tagging scheme:

cimg/node:<node-version>

<node-version> - The version of Node.js to use. This can be a full SemVer point release (such as 10.16.3), or just the minor release (such as 12.6), or a version alias. This Node.js image has two version aliases, "current" and "lts". This aliases will always point to the latest "current" and latest "lts" releases that Node.js has as according to their website. Keep in mind that using an alias tag will be less stable that specifying a full SemVer version. If you use the minor release tag, it will automatically point to future patch updates as they are released by Node.js. For example, the tag 12.6 points to Node.js v12.6.0 now, but when the next release comes out, it will point to Node.js v12.6.1.

Development

Images can be built and run locally with this repository. This has the following requirements:

• local machine of Linux (Ubuntu tested) or macOS
• modern version of Bash (v4+)
• modern version of Docker Engine (v19.03+)

Cloning For Community Users (no write access to this repository)

Fork this repository on GitHub. When you get your clone URL, you'll want to add --recurse-submodules to the clone command in order to populate the Git submodule contained in this repo. It would look something like this:

git clone --recurse-submodules <my-clone-url>

If you missed this step and already cloned, you can just run git submodule update --recursive to populate the submodule. Then you can optionally add this repo as an upstream to your own:

git remote add upstream https://github.com/CircleCI-Public/cimg-node.git

Cloning For Maintainers ( you have write access to this repository)

Clone the project with the following command so that you populate the submodule:

git clone --recurse-submodules [email protected]:CircleCI-Public/cimg-node.git

Generating Dockerfiles

Dockerfiles can be generated for a specific Node.js version using the gen-dockerfiles.sh script. For example, to generate the Dockerfile for Node.js v12.16, you would run the following from the root of the repo:

./shared/gen-dockerfiles.sh 12.16.3=lts

The generated Dockerfile will be located at ./12.16/Dockefile. To build this image locally and try it out, you can run the following:

cd 12.16
docker build -t test/node:12.16.3 .
docker run -it test/node:12.16.3 bash

Building the Dockerfiles

To build the Docker images locally as this repository does, you'll want to run the build-images.sh script:

./build-images.sh

This would need to be run after generating the Dockerfiles first. When releasing proper images for CircleCI, this script is run from a CircleCI pipeline and not locally.

Publishing Official Images (for Maintainers only)

The individual scripts (above) can be used to create the correct files for an image, and then added to a new git branch, committed, etc. A release script is included to make this process easier. To make a proper release for this image, lets's use the fake Node version of Node v9.99, you would run the following from the repo root:

./shared/release.sh 9.99=alias

This will automatically create a new Git branch, generate the Dockerfile(s), stage the changes, commit them, and push them to GitHub. The commit message will end with the string [release]. This string is used by CircleCI to know when to push images to Docker Hub. "alias" would be "current" or "lts" depending on the version. All that would need to be done after that is:

• wait for build to pass on CircleCI
• review the PR
• merge the PR

The main branch build will then publish a release.

Incorporating Changes

How changes are incorporated into this image depends on where they come from.

build scripts - Changes within the ./shared submodule happen in its own repository. For those changes to affect this image, the submodule needs to be updated. Typically like this:

cd shared
git pull
cd ..
git add shared
git commit -m "Updating submodule for foo."

parent image - By design, when changes happen to a parent image, they don't appear in existing Node.js images. This is to aid in "determinism" and prevent breaking customer builds. New Node.js images will automatically pick up the changes.

If you really want to publish changes from a parent image into the Node.js image, you have to build a specific image version as if it was a new image. This will create a new Dockerfile and once published, a new image.

Node specific changes - Editing the Dockerfile.template file in this repo is how to modify the Node.js image specifically. Don't forget that to see any of these changes locally, the gen-dockerfiles.sh script will need to be run again (see above).

Contributing

We encourage issues and pull requests against this repository.

Please check out our contributing guide which outlines best practices for contributions and what you can expect from the images team at CircleCI.

Additional Resources

CircleCI Docs - The official CircleCI Documentation website.
CircleCI Configuration Reference - From CircleCI Docs, the configuration reference page is one of the most useful pages we have. It will list all of the keys and values supported in .circleci/config.yml.
Docker Docs - For simple projects this won't be needed but if you want to dive deeper into learning Docker, this is a great resource.

License

This repository is licensed under the MIT license. The license can be found here.

cimg-node's Issues

Recent image broke `npm --prefix DIR run` functionality

Sometime on May 11, 2022, cimg/node:lts-browsers was updated and our current setup got broken. The details are:

• the latest "good" image is
  cimg/node@sha256:c8ea4df07599f2c676c81f6dfecb22237da28428997589b28e8afa0afee8e96f
• the current "bad" image is cimg/node@sha256:c74edbc4f04bab52e47ca8a77e5a44cfb6241a13a87687262e554a345ac5359d

The minimum project demonstrating the problem is available at https://github.com/korya/circleci-node-issue.

Below are the steps to reproduce the problem using https://github.com/korya/circleci-node-issue.

Reproduction

Good old image

docker run -ti --rm -v `pwd`:/home/circleci/project cimg/node@sha256:c8ea4df07599f2c676c81f6dfecb22237da28428997589b28e8afa0afee8e96f
# Inside the image
bash
npm i
npm run test
# Result: the command succeeds and outputs `SUCCESS!`

Overall output should be as follows:

 $ docker run -ti --rm -v `pwd`:/home/circleci/project cimg/node@sha256:c8ea4df07599f2c676c81f6dfecb22237da28428997589b28e8afa0afee8e96f
$ _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.

$ bash
circleci@cea7ca1f3f90:~/project$ npm i

up to date, audited 3 packages in 454ms

found 0 vulnerabilities
circleci@cea7ca1f3f90:~/project$ npm run test

> @korya/[email protected] test
> npm --prefix packages/sub-project test


> @korya/[email protected] test
> ./test.sh

v16.15.0
SUCCESS!
npm notice
npm notice New minor version of npm available! 8.5.5 -> 8.10.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.10.0
npm notice Run npm install -g [email protected] to update!
npm notice
npm notice
npm notice New minor version of npm available! 8.5.5 -> 8.10.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.10.0
npm notice Run npm install -g [email protected] to update!
npm notice

Bad new image

docker run -ti --rm -v `pwd`:/home/circleci/project cimg/node@sha256:c74edbc4f04bab52e47ca8a77e5a44cfb6241a13a87687262e554a345ac5359d
# Inside the image
bash
npm i
npm run test
# Expected result: the command succeeds and outputs `SUCCESS!`
# Actual result: the command fails with
#     /usr/bin/env: ‘node’: No such file or directory

Overall output I get is:

$ docker run -ti --rm -v `pwd`:/home/circleci/project cimg/node@sha256:c74edbc4f04bab52e47ca8a77e5a44cfb6241a13a87687262e554a345ac5359d
$ _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
bash
circleci@406d4bbc3b6c:~/project$ npm i

up to date, audited 3 packages in 467ms

found 0 vulnerabilities
circleci@406d4bbc3b6c:~/project$ npm run test

> @korya/[email protected] test
> npm --prefix packages/sub-project test


> @korya/[email protected] test
> ./test.sh

nvm is not compatible with the "npm_config_prefix" environment variable: currently set to "/home/circleci/project/packages/sub-project"
Run `unset npm_config_prefix` to unset it.
./test.sh: line 5: node: command not found
/usr/bin/env: ‘node’: No such file or directory
npm notice
npm notice New minor version of npm available! 8.5.5 -> 8.10.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.10.0
npm notice Run npm install -g [email protected] to update!
npm notice

Latest image

At this moment, 2022-05-12 08:00 ET, the latest cimg/node@lts-browsers is
broken.

docker run -ti --rm -v `pwd`:/home/circleci/project cimg/node:lts-browsers
# Inside the image
bash
npm i
npm run test
# Expected result: the command succeeds and outputs `SUCCESS!`
# Actual result: the command fails with
#     /usr/bin/env: ‘node’: No such file or directory

Feature Request: cimg/node browsers arm64 support

For our official CircleCI Docker Convenience Image support policy, please see CircleCI docs.

This policy outlines the release, update, and deprecation policy for CircleCI Docker Convenience Images.

---

Describe the Feature Request
Create and publish arm64 image for cimg/node:latest-browsers

Is your feature request related to a particular problem?
cimg/node:latest images contain support for arm64 (thank you!), but the need to run Cypress test with the -browsers images prevents us from leveraging the new arm support.

Why arm64? CircleCI runners on arm have more ram allocated per CPU than similar linux-based x64 runners. We'd like to use arm64 across the board to help improve stability of some memory-intensive builds.

Why can't you use existing -browsers images for specific tasks only? Due to some workspace-level caching of binaries, all build nodes need to have the same architecture.

Additional Data
I see in the original PR to add arm64 support to cimg-shared by @BytesGuy, browser variants were skipped due to an issue related to Selenium service, but I wasn't able to figure out exactly what that was

How will this feature request benefit CircleCI jobs using this image?
This will increase the support for arm-based images, allowing customers to more easily transition to these images without having to re-think part of their build pipeline

Describe the solution you would like to see
I would like to see cimg/node publishing 20.8.1-browsers and above with linux/arm64 tags and support. This image should contain the same set of browsers/tools that are included in the linux/amd64 build

Describe alternatives you have considered
The alternatives for us are a revamp of the current build pipeline or staying on linux/amd64 images, both of which are undesirable

Docker image aliases for major version

Can we get more aliases for the major releases?

Specifically these docker tags on cimg/node:

• 10
• 12
• 14
• 15

Otherwise our CI pipelines get stale too quick as developers hardcode minor and patch versions in the pipeline config 😢

Mutable tag request :stable

:<node-version>-stable
is great if I want to lock to a specific version of node, but I'd really like to auto-select the stable version and revision of node a la nvm install stable
THX

Yarn 3 has issues as a result of build time variables NODE_VER and YARN_VER

We recently had an issue with building our project in production, getting this error early on in the build:

#!/bin/bash -eo pipefail
yarn install --immutable
Usage Error: Unrecognized or legacy configuration settings found: ver - run "yarn config -v" to see the list of settings supported in Yarn (in <environment>)

$ yarn install [--json] [--immutable] [--immutable-cache] [--check-cache] [--inline-builds] [--mode #0]

Exited with code exit status 1

the accompanying config code is the following:

jobs:
  build:
    docker:
      - image: cimg/node:14.19
    steps:
      - checkout
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: |
            # unset Docker build time variables, yarn 3 don't like that
            unset NODE_VER
            unset YARN_VER
            yarn install --immutable

After some difficulty, we tracked the issue down to NODE_VER and YARN_VER variables, likely build time variables for the container. Unsetting these values allowed us to run yarn properly.

I believe we need these two variable names (NODE_VER and YARN_VER) to be changed in order to avoid this issue in the future.

cimg/node:16.18 & cimg/node:16.19: "Mongod instance closed with code \"127\"" was thrown, throw an Error :)

Startring with the 16.18.0 node docker image, we have been seeing failures in our tests running through CircleCI. THe issue is only present when running our tests in the following images:

• cimg/node:16.18.0
• cimg/node:16.19.0

cimg/node:16.17.0 works just fine.

The issue looks to be around our tests that are testing mongodb things:

1) TableService
       "before all" hook in "TableService":
     Error: the string "Mongod instance closed with code \"127\"" was thrown, throw an Error :)
      at thrown2Error (/home/circleci/project/Ready.Table/node_modules/mocha/lib/runner.js:1241:10)
      at Runner.fail (/home/circleci/project/Ready.Table/node_modules/mocha/lib/runner.js:443:11)
      at cbHookRun (/home/circleci/project/Ready.Table/node_modules/mocha/lib/runner.js:532:14)
      at done (/home/circleci/project/Ready.Table/node_modules/mocha/lib/runnable.js:310:5)
      at /home/circleci/project/Ready.Table/node_modules/mocha/lib/runnable.js:377:11

Running our tests on local machines using node 16.18 and 16.19 work just fine.

Update README for permissions

There is no need to use sudo with npm as may be the case with local machines or other images. documenting this helps to clear any confusion with new and existing users who have typically used run npm with sudo permissions

shallow checkout

Any reason not to do a shallow checkout? https://support.circleci.com/hc/en-us/articles/360045096514-Shallow-Repository-Cloning

Upgrading `npm` version

Is there a way to upgrade the NPM version within these containers? I'm not able to run npm i -g npm@7 to install NPM 7 in the LTS container, since NPM 6 is the current default for Node 14.

> docker run -it --entrypoint bash cimg/node:lts
circleci@c39a93842b99:~/project$ npm i -g npm@7
npm ERR! code EACCES
npm ERR! syscall access
npm ERR! path /usr/local/lib/node_modules/npm/node_modules/abbrev
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules/npm/node_modules/abbrev'
npm ERR!  [Error: EACCES: permission denied, access '/usr/local/lib/node_modules/npm/node_modules/abbrev'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'access',
npm ERR!   path: '/usr/local/lib/node_modules/npm/node_modules/abbrev'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/circleci/.npm/_logs/2021-05-12T23_12_57_995Z-debug.log

Upgrade Node.js images with the latest security releases

It was published recently a High level vulnerability on OpenSSL.
We would like to be upgrading to be up-to-date with the security release. The latest on the LTS branch is the 16.14.2.
These releases also impact others branches.

Reference:
https://nodejs.org/en/blog/vulnerability/mar-2022-security-releases/

Snyk Critical Vulnerabilities

Hello,

Based on Snyk report there are 5 Crytical vulnerabilities.
Is this something Circle Ci would be interested in fixing?
How does Circle Ci manage dependency management for the docker/orbs provided

?

thank you

Latest release of node:lts-browsers breaks corepack prepare/activate

After the latest release of the cimg/node:lts-browsers my circle-ci builds started failed due to lacking permissions on /usr/local/bin folder.

I am using corepack to install and activate pnpm as package manager which used to work great but since the last release my builds are failing with the error below:

corepack enable && corepack prepare $(node -p "require('./package.json').packageManager") --activate
Internal Error: EACCES: permission denied, symlink '../lib/node_modules/corepack/dist/pnpm.js' -> '/usr/local/bin/pnpm'
Error: EACCES: permission denied, symlink '../lib/node_modules/corepack/dist/pnpm.js' -> '/usr/local/bin/pnpm'

Exited with code exit status 1
CircleCI received exit code 1

Specifically the command corepack enable fails. As this happens on all recent cimg/node releases it is probably a change in the base image. Either in the ubuntu image or in cimg/base.

This will also affect other tools that create symlinks in /usr/local/bin; a quick solution would be to grant write permission on /usr/local/bin but not sure if it makes sense to do that in cimg-node or bring the issue to one of the upstream images that cimg-node is based on.

Switching back to an older version of cimg-node resolves the issue: cimg/node:16.6-browsers or cimg/node:18.4-browsers

• Failing built
• Successful built using the same image 2 days ago

major version tags

Would it be possible to also publish tags just with the major version, as currently done in circleci/node? For example, cimg/node:10 and cimg/node:12.

Latest version of image run out of memory

The latest versions of cimg/node:lts-browsers are running out of memory.

Our CI job is the same and does not change but:

• cimg/node@sha256:5f2070d5e582a32f977e14e8d7e611acf91e4affb10dc4cf9e536e040dfd7038 runs out of memory and fails
• cimg/node@sha256:542f4764aa5e3dd7e9372ac3ede108639cf95bc752b5065ce0d3f8941a10834e works as expected and the job succeeds

The failing job is https://app.circleci.com/pipelines/github/PlanitarInc/walk-inside-app/6599/workflows/7b50389c-d6e8-4041-8683-5ab876f620d8/jobs/42888/steps

Please let me know if you need more details.

Bug Report: Missing Node.js 20.6.1 release

Node.js 20.6.0 introduced a regression that broke large part of the ecosystem (nodejs/node#49497). That regression has been fixed and released as 20.6.1 (https://nodejs.org/en/blog/release/v20.6.1).

cimg/node:current still points to 20.6.0, and cimg/node:20.6.1 does not exist. Would it be possible to publish it?

`npm install -g gh-pages` failed in `cimg/node:current` image

We are using cimg/node:current as base image for one of the CI pipeline. Today it failed without any incoming code changes on our end. The specific failed command is npm install -g gh-pages. The error traceback is:

npm ERR! code EACCES
npm ERR! syscall mkdir
npm ERR! path /usr/local/lib/node_modules/gh-pages
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/gh-pages'
npm ERR!  [Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/gh-pages'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/usr/local/lib/node_modules/gh-pages'
npm ERR! }
npm ERR! 
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR! 
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/circleci/.npm/_logs/2022-07-29T00_54_08_567Z-debug-0.log


Exited with code exit status 243

I tried to ssh into CI container and run this command with admin permission, i.e. npm install -g gh-pages and it worked. However, in your doc it's not encouraged to do so. I'm hoping you could provide some insights here. Thanks.

Attached below is all the steps happen before the failed command:

update-docs:
    docker:
      - image: cimg/node:current
    steps:
      - attach_workspace:
          at: /tmp/workspace/
      - checkout
      - run:
          name: Copy all docs into repo
          command: |
            cp -r /tmp/workspace/docs/* docs/
      - run:
          name: Install gh-pages utility
          command: |
            npm install -g gh-pages

symlink `npm`, `node` to /usr/loca/bin

Currently sudo npm fails to find the path on 18.x images because of use of nvm.

Symlink-ing like this, https://stackoverflow.com/questions/21215059/cant-use-nvm-from-root-or-sudo/40078875#40078875 resolves the issue, while users of the images can do this manually with extra steps, it would be nicer for this to be out of the box on upstream build stage.

Support corepack

It would be nice to use corepack to avoid checking in the .yarn/releases/ binary, but running corepack enable fails with permission errors. For now, we can workaround it with --install-directory, but it would be great to get first-class support

Support pnpm

Hi 👋 I was wondering if it would be possible to include pnpm in this (or another) node image as package manager. It's already ship with npm and yarn, maybe it could also include pnpm 🙂

• https://pnpm.io/
• https://github.com/pnpm/pnpm

permissions on node 16:17

The permissions seem to have changed with cimg such that in 16.16, npm wasn't in the path, so you couldn't run
sudo npm -g install xyz, but you could run npm -g install xyz, and it would work

With node 16.17, /usr/local/lib and /usr/local/lib/node_modules is owned by uid 1001, so the opposite is true.

I'm glad the shim is gone, but just wanted to mention the somewhat breaking change.

Using node 10.18.0 git command display warnings Permission denied

Hello,

I switch to this new cimg/node:10.18.0 and when I run the command git add test.txt I get warnings:

warning: unable to access '/home/circleci/.config/git/ignore': Permission denied
warning: unable to access '/home/circleci/.config/git/attributes': Permission denied

I have open a support ticket for this but the answer is to use "a Machine User or a Deployment Key" and I don't get why and how this could solve those warnings.

Here is the full config to reproduce warnings:

  sample:
    docker:
      - image: cimg/node:10.18.0
    working_directory: ~/repo
    steps:
      - checkout
      - run: touch test.txt && git add test.txt

I didn't get any warnings when I use circleci/node:10.18.0

Recent versions of image cause jest to fail

The recent versions of cimg/node:lts-browsers cause Jest to fail our unit test.

The problem is in rendering a localized date. The following test fails when invoked using LANG=en_US TZ=Pacific/Tahiti jest:

test('render localized date', () => {
  const str = new Date('2017-10-29T14:55:30Z').toLocaleString(undefined, {
    month: 'long',
    day: 'numeric',
    hour: 'numeric',
    weekday: 'long',
    timeZoneName: 'short',
    timeZone: 'America/Toronto',
  });

  expect(str).toEqual('Sunday, October 29, 10 AM EDT');
});

It worked this way in CircleCI for years. It still works on my laptop (MacOs, Node v18.5.0).

But it stopped working in recent versions of cimg/node:lts-browsers, it fails with the following error message:

expect(received).toEqual(expected) // deep equality

Expected: "Sunday, October 29, 10 AM EDT"
Received: "Sunday, October 29 at 10 AM EDT"

That is it returns Sunday, October 29 at 10 AM EDT instead of Sunday, October 29, 10 AM EDT. (Side note: we noticed that the former is usually returned by Chrome).

Summary:

• A good version of the image is cimg/node@sha256:542f4764aa5e3dd7e9372ac3ede108639cf95bc752b5065ce0d3f8941a10834e. The tests works as expected.
• A recent bad version of the image is cimg/node@sha256:5f2070d5e582a32f977e14e8d7e611acf91e4affb10dc4cf9e536e040dfd7038. The tests fail with the error above.
• The failing build: https://app.circleci.com/pipelines/github/PlanitarInc/walk-inside-app/6596/workflows/f3e2a1b6-8c2b-45ea-85e2-521812b9111d/jobs/42877

Base Ubuntu version changing

I know cimg/base normally tracks relatively recent stuff on some kind of predictable cadence. That said, is there a way to get a newer node tag (e.g., 14.21) but with the older Ubuntu version, via another tag (I didn't see one available)?

I realize it may not be possible, but IMO, it would be nice if these versions could stay predictable within a set of versions (i.e., when going from 14.20 to 14.21), or at least be accessed via a tag like 14.21-buster.

(issue prompting me to open this: when I bumped our default tag from 14.20 to 14.21, we no longer had OpenSSL 1.1 available from the bump to jammy, which meant some stuff broke in our builds that I had to resolve with a kind of ugly hack).

fix Dockerfile.template due to path variable

node version is hard coded into path variable; however, with nvm, this path needs to be variable in order for users to switch versions

Bug Report: wrong LTS version

Note: We also welcome PRs to fix bugs! This helps us take action faster where a bug has been identified!

For our official CircleCI Docker Convenience Image support policy, please see CircleCI docs.

This policy outlines the release, update, and deprecation policy for CircleCI Docker Convenience Images.

---

Describe the bug
Incorrect Node version installed which causes conflicts with package engines

npm ERR! notsup Required: {"npm":">=10.0.0","node":">=20.9.0"}
npm ERR! notsup Actual:   {"npm":"9.8.1","node":"v18.18.0"}

To Reproduce
Create a job that uses an lts image

  deploy:
    resource_class: large
    docker:
      - image: cimg/node:lts 

Expected behavior
The image should contain the current LTS version of node - Node.js 20.9.0 and 10.1.0
https://nodejs.org/en
https://nodejs.org/en/download/releases#looking-for-latest-release-of-a-version-branch

Workarounds
None - The correct version can be hardcoded in the image with cimg/node:20.9.0, but this image is not available at https://github.com/CircleCI-Public/cimg-node/tree/main/20.9

Screenshots and Build Links

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#engines

Additional context
The LTS version change announcement happened 2 days ago - https://nodejs.org/en/blog/release/v20.9.0

How to specify screen resolution?

I can't find a way to change the screen resolution for the ubuntu image in order to run browser tests.

Change Publish branch to main after switch is made

if [ "${CIRCLE_BRANCH}" == "master" ]; then to if [ "${CIRCLE_BRANCH}" == "main" ]; then

• Comb through for any remaining references to master

Feature Request: Include Bun (bun install)

Since we already got yarn and pnpm, maybe consider also adding bun? benchmarks for bun install are impressive.

Publish v16.16.0 - new LTS version

The new LTS version (v16.16.0) of node was published last week - see here. As it's a security update, could a cimg build of v16.16.0 please be prioritised?

Global packages require sudo to install

Node appears to be not configured after installation and mishandles global npm packages.
https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally

Installing Node via NVM would automatically configure pathing for global packages, or additional steps can be taken to create the global package path.

This issue was reported originally by the salesforce orb here: CircleCI-Public/Salesforce-sfdx-cli-orb#17

sudo would work to install the packages but by NPM's own documentation this is not advised.

The Node Orb's install command should be unaffected as it assumes you are using NVM and will install it if not present.

Migrating from circleci/node:16.13-browsers to cimg/node:16-13

Good Afternoon,

I'm forced to migrate the setup we have which is using circleci/node:16-13-browsers as base to create my docker container to cimg/node-16-13. all the documentation I have found are telling me to use orbs. the problem I'm trying to figure out though is am I able to use these orbs without creating a circleci account. like I didn't have to use the circleci dashboard to do any of this, I was just using a static image runs tests against.

is there any docs on how to use the circleci orbs and not have to make an account?

Node-gyp issues python2

I'm using node-sass for SASS styling in my React app. However the build fails due to python2 missing, is this taken into account, or should I install python myself.

npm not working for root with version 16.15

Problem

When running a npm install -g which requires sudo permissions in some cases we encountered the following error starting with 16.15 (or lts alias): sudo: npm: command not found

In previous version the npm command was available to all users without special setup.

Reproduce

Use cimg/node:16.15 or cimg/node:lts and try to run sudo npm i -g <any-package>

Cause

The cause for this seems to be introduced with this commit:
9eedc18#diff-edec1cd2bb136ae7da8a926182e4c74d15c783bbccbe3d1cc8da43472c0e6c18R14

The nvm script is only sourced for the circleci user, but not for any other user including root.

Expected Behaviour

Expected behaviour would be that npm works for all users, as it did with all previous versions.

Publish v16.9.1

This new version contains some security updates, please increase priority of this release.

-ubuntu and -browsers extensions

Hey there!

I want to know whether there are any plans to add support for these label extensions to directly declare them in an executor. They exist in the current-gen images.

Example

cimg/node:10.20-buster-browsers

How to use the `-browsers` variants?

I might be missing something very obvious here. I am trying to migrate a setup using "legacy" circleci Docker image to cimg ones. Some of them run on circleci/node:14-browsers which I migrated to cimg/node:14.17-browsers.

After having done so, my tests aren't able to run anymore as the chrome executable cannot be found anymore. SSHing into the build I found that no browser at all (Firefox, Chrome) is installed in the container. Looking at the Dockerfile here: https://github.com/CircleCI-Public/cimg-node/blob/63393c4d8cafdc66c628eeb9f25bd3b39ca8bb2d/14.17/browsers/Dockerfile I can also see that only browser dependencies, but no browsers are being installed.

Is this expected behavior? Am I supposed to install the browsers I require myself with the next gen images or am I doing something wrong? (I would be fine with installing the browsers myself, I would just find it very surprising if I had to do it in a -browsers variant, so I wanted to check if I'm doing something wrong here)

Yarn v2

This should be announced via CircleCI Discuss before we incorporate it since it's a major version change.

Node.js v14 is scheduled to release 2020-04-21. We can try to update Yarn then, though that is 76 days away.

Python not in image?

Just updated one of my projects to use the circleci/[email protected] Orb. Doing so has resulted in my build failing due to python not found. I was previously using circleci/node:lts

Is there a reason for the difference between the two images and why python is not included as a core dev tool?

cimg/node:16.13

Would be nice to have cimg/node:16.13 as it became LTS yesterday 🙏

Publish major version (only) tag pointing at the latest build for a major node version

In the same way that you already republish the, for example, 18.10 tag when you publish each of the 18.10.1, 18.10.2, ... images, which then gives a tag pointing at the latest v18.10.x image, it would be really helpful to have a plain '18' tag that points at the latest v18.x.y image.

This would enable us to have a build that tests our published component against the latest v14, v16, v18, etc images so that we get an early warning if a new version of Node is released that causes problems with our component. Right now, we'll have to keep manually bumping the minor versions for each major version mentioned in our workflow.

Can you create this image please?

Hi team!

Happy customer here that can be happier if we solve an issue I'm having.

Spin-up time is still 40+ seconds time for me, which it's hella crazy, and can't reduce it further. I need GCP + Node to run my deployments since we're deploying our apps to Google Cloud.

I'm using this image that a guy did because it combined both. Can u guys create an image for gcp + node or provide me any solution? I don't know anything about docker btw lol.

NikolajDL/gcloud-sdk-nodejs#2

Thanks

node:current - /bin/bash: line 6: npm: command not found

Getting npm command not found error when trying the latest tag 18.1

Browser images without browsers

Summary:

As referenced in this code snippet there are browser images for NodeJS that are shipped with the full set of dependencies of common browsers (i.e. firefox and chrome), but they never actually install the browser binaries.

cimg-node/16.3/browsers/Dockerfile

Lines 28 to 54 in a2864c1

	# Firefox deps
	sudo apt-get install -y --no-install-recommends --no-upgrade \
	libdbus-glib-1-2 \
	libgtk-3-dev \
	libxt6 \
	&& \
	# Google Chrome deps
	# Some of these packages should be pulled into their own section
	sudo apt-get install -y --no-install-recommends --no-upgrade \
	fonts-liberation \
	libappindicator3-1 \
	libasound2 \
	libatk-bridge2.0-0 \
	libatspi2.0-0 \
	libcairo2 \
	libcups2 \
	libgbm1 \
	libgdk-pixbuf2.0-0 \
	libgtk-3-0 \
	libpango-1.0-0 \
	libpangocairo-1.0-0 \
	libxcursor1 \
	libxss1 \
	xdg-utils \
	xvfb \
	&& \
	sudo rm -rf /var/lib/apt/lists/*

Actual behaviour:

• google-chrome --version is not a binary/executable
• firefox --version is not a binary/executable

Expected behaviour

• google-chrome --version is returning the latest version of chrome
• firefox --version is returning the latest version of firefox

Technical insights:

Coming from circleci/node, there were actual browser binaries being shipped: https://github.com/CircleCI-Public/circleci-dockerfiles/blob/master/node/images/15.9.0-buster/browsers/Dockerfile

Feature Request: Update open JDK to the next LTS

Describe the Feature Request
Please update the Open JDK for Java to the next LTS version. The current one is about to be depricated.

Is your feature request related to a particular problem?
Our workflow gives a warning the the current Java version is soon to be depricated.

How will this feature request benefit CircleCI jobs using this image?
To be able to use this cimg the java version needs to be updated or we need to create a custum image.

Describe the solution you would like to see
update open JDK to version 17

Describe alternatives you have considered
none

Using the image in other CI tools

Hi Team ,

Can we use this image with other CI tools like GitHub actions or Jenkins and expect to work the same ?

cimg slower than old image

The new image is twice as slow, mainly due to Time to upload agent and config

Compare https://app.circleci.com/pipelines/github/15five/fifteen5/30221/workflows/1d50e294-90ff-4e99-9e42-76c2da7d4c48/jobs/186258 (old image) with https://app.circleci.com/pipelines/github/15five/fifteen5/30228/workflows/252fd8ae-7cc7-4e63-8bc3-1f00e33e027a/jobs/186289

old: (3 seconds)

Build-agent version 1.0.34446-05905e76 (2020-06-16T11:27:30+0000)
Docker Engine Version: 18.09.6
Kernel Version: Linux f0b56ba200d0 4.15.0-1067-aws #71-Ubuntu SMP Thu Apr 30 13:51:43 UTC 2020 x86_64 Linux
Starting container circleci/node:12
  image is cached as circleci/node:12, but refreshing...
12: Pulling from circleci/node
Digest: sha256:25b032177e0c69947a8a31e91370fd6fea100689e63c4ee011bceecd75589de2
Status: Image is up to date for circleci/node:12
  pull stats: N/A
  time to create container: 562ms
  using image circleci/node@sha256:25b032177e0c69947a8a31e91370fd6fea100689e63c4ee011bceecd75589de2
Time to upload agent and config: 953.114164ms
Time to start containers: 1.544365849s

New: (6 seconds)

Build-agent version 1.0.34446-05905e76 (2020-06-16T11:27:30+0000)
Docker Engine Version: 18.09.6
Kernel Version: Linux 2bebb7165f7d 4.15.0-1067-aws #71-Ubuntu SMP Thu Apr 30 13:51:43 UTC 2020 x86_64 Linux
Starting container cimg/node:12.18
  image is cached as cimg/node:12.18, but refreshing...
12.18: Pulling from cimg/node
Digest: sha256:13a99486762328eefc90bf72f897be133176d1cf1117660e69406b44c441537e
Status: Image is up to date for cimg/node:12.18
  pull stats: N/A
  time to create container: 499ms
  using image cimg/node@sha256:13a99486762328eefc90bf72f897be133176d1cf1117660e69406b44c441537e
Time to upload agent and config: 3.51082595s
Time to start containers: 1.891967343s

I tried re-running the workflow but for some reason the image wasn't cached anymore so I couldn't get a accurate comparison. Maybe this was a one-off speed difference or something.

cimg/node:14.17.4 policykit vulnerability CVE-2021-4034

cimg/node:14.17.4 which uses cimg/base:2021.07 as the base has policykit-1/now 0.105-26ubuntu1.1 amd64 installed which is subject to the vulnerability CVE-2021-4034.

Ubuntu has pushed out new policykit-1 patch to mitigate this issue.

I can see the latest base image cimg/base:2022.02-20.04 has the updated policykit-1 0.105-26ubuntu1.2 installed.

I would like to request an update of the base image for cimg/node:14.17.4 or any other node images use the cimg/base:2021.07 image.

cannot instal aws-s3 orb

/usr/bin/env: ‘python’: No such file or directory

/home/circleci/.local/bin is in path but doesn’t exist by default

While apps/scripts should ideally check that ~/.local/bin exists before trying to do something with it, it might be an idea to have the directory exist by default in the image given that it’s already in $PATH.

(Update: Note, it’s the ~/.local directory that doesn’t exist.)

(Thanks, by the way, this image is hugely useful.) :)

Yarn global bin directory not in path

If you install a package with yarn global install, it won't currently be available to use in subsequent commands, since Yarn's global binary path isn't in the bash path.

Since Yarn is pre-installed in this image, it makes sense to also add the global binary path to the environment that's used by the commands.