I use Node 22 in my Bitbucket pipeline, and run tests with the native Node test runner, and collect coverage with the native Node coverage reporter.
In Node 22.11 it takes around 6 a 7 minutes, but Node 22.12 till 22.14 takes more than 20 minutes, so around 3x slower.
Locally it doesnt matter a lot which Node version I use.
Do you have any idea why Node 22.12+ is much slower than 22.11 and earlier?
Hi Pieter,
My first question is the same as Gajesh's below, does this step run on Atlassian's infrastructure or with a self-hosted runner?
If it runs with a self-hosted runner, which type of runner is it (Linux Docker, Linux Shell, MacOS or Windows runner)?
If it runs on Atlassian's infrastructure, do you use a different Docker image as a build container for Node 22.11 and another one for 22.12+? Or is it the same Docker image, and you install Node during the build?
Some things that come to mind as possible reasons are:
Assuming again that you run this step on Atlassian's infrastructure, I would recommend debugging the step locally with Docker using the following guide and then comparing performance:
This way, you reproduce in an environment as close as possible to the Pipelines environment and that can help us narrow down whether the issue is with Pipelines or not. I would suggest running the step a few times locally as per the guide above, so that you get an average of the time it needs to run. Please feel free to let me know what these local tests show.
Kind regards,
Theodora
I run on Atlassian's infrastructure.
I use the `image: node:22`
I have add multiple in parallel with the same scripts, running on different Node versions, like Node 20, 22.10, 22.11, 22.12, 22.13 and 22.14
I see that 22.12 and later are 3x slower than earlier 22.x and 20.x
So I don' t install Node, I use the official Node docker image.
And I scale it up to a size of 4x, for all Node versions in parallel, what should be more than enough.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Pieter and @Jakob Schröter,
Troubleshooting the slow step locally with Docker as per the guide I shared above is the way to narrow down if this seems to be a Pipelines-specific issue or not.
If you are using larger size steps, you can adjust the command on Step 4 of the guide to use the same memory and cpus as your Pipelines step. The command on Step 4 uses 4 GB of memory and 4 CPUs which applies to 1x steps, you can can adjust it accordingly depending on the size of your step (see here for reference: https://support.atlassian.com/bitbucket-cloud/docs/step-options/#Size).
When you reach Step 5 of the guide, you can add the command time in front of every command of your step to monitor how much time it takes to run. If you run it a couple of times locally and you observe faster times on average than the respective Pipelines step, you can create a ticket with the support team, share the results and the URL of a step that runs longer in Pipelines, for further investigation.
You can create a ticket via https://support.atlassian.com/contact/#/, in "What can we help you with?" select "Technical issues and bugs" and then Bitbucket Cloud as product. When you are asked to provide the workspace URL, please make sure you enter the URL of the workspace that is on a paid billing plan to proceed with ticket creation.
Kind regards,
Theodora
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We're having the same issue. Using Atlassian cloud runners, standard `node:22.14.0` image and Vitest instead of the native test runner. See https://github.com/vitest-dev/vitest/issues/7302#issuecomment-2671813675 for more details and links to public repo.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Are you using the Atlassian Provided Cloud Runner or running your self-hosted runners?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.