NextJS, SonarCloud and Bitbucket scans crashing

SonarCloud
1

Background:

We are running a NextJS site which consists of lots of microservices in tree format:

apps/app1
apps/app2 (etc etc)
...
libs/shared
libs/marketing-site
libs/otherstuff (etc etc)

Each directory has it’s own tsconfig.json and src directory.

  • ALM + CI used: Bitbucket Cloud
  • Scanner command:
    - step: &sonarScanLibsShared
        name: Sonar Scan Libs - Shared
        size: 2x
        caches:
          - sonar
        script:
          - pipe: sonarsource/sonarcloud-scan:1.4.0
            variables:
              SONAR_SCANNER_OPTS: -Xmx256m
              SONAR_TOKEN: ${SONAR_TOKEN_LIBS_SHARED}
              EXTRA_ARGS: '-Dsonar.projectBaseDir=libs/shared -Dsonar.javascript.node.maxspace=7168'

The ‘active’ bit of our sonar-project.properties file is:

sonar.exclusions=**/node_modules/**,**/.storybook/**,**/.storybook/tsconfig.json,**/src/main.tsx,**/src/index.ts,**/*.min.js,**/jest.config.ts,**/*.spec.{js,jsx,ts,tsx},**/*.test.{js,jsx,ts,tsx},**/*.{story,stories}.{js,jsx,ts,tsx}
sonar.test.inclusions= **/*.spec.{js,jsx,ts,tsx},**/*.test.{js,jsx,ts,tsx},**/*.{story,stories}.{js,jsx,ts,tsx}
  • Languages of the repository - NextJS / React
  • Error observed:

When running sonarscan - a single file repeats and then a crash is seen most of the time - but not always - e.g:

INFO: 124/203 files analyzed, current file: /opt/atlassian/pipelines/agent/build/libs/marketing-site/util-api/src/lib/marketing-site-util-api.spec.ts
INFO: 124/203 files analyzed, current file: /opt/atlassian/pipelines/agent/build/libs/marketing-site/util-api/src/lib/marketing-site-util-api.spec.ts
ERROR: eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory. Consider setting sonar.javascript.node.maxspace to higher value (e.g. 4096).
ERROR: Failure during analysis, Node.js command to start eslint-bridge was: node --max-old-space-size=7168 /opt/atlassian/pipelines/agent/build/libs/marketing-site/.scannerwork/.sonartmp/eslint-bridge-bundle/package/bin/server 45083 127.0.0.1 /opt/atlassian/pipelines/agent/build/libs/marketing-site/.scannerwork true false /opt/atlassian/pipelines/agent/build/libs/marketing-site/.scannerwork/.sonartmp/eslint-bridge-bundle/package/custom-rules980193960290417194/package
java.lang.IllegalStateException: eslint-bridge is unresponsive
	at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.request(EslintBridgeServerImpl.java:378)

But the file it “trips” on is not always the same between runs.

This looks to be a memory issue - but the codebase isn’t that big (the whole apps directory is 114 files - the whole libs directory is 1k. They’re all small files - the only one over 0.5Mb is package-lock.json.

We’ve tried targetting sections via the monorepo feature - (so the command above is for just for libs/marketing-site for example)

We’ve also given the process the max memory Bitbucket will allow (7Gb for the node space - 1Gb shared between sonarscan and the general container) - but still no dice.

Any ideas what we can do to fix it?

2

I am experiencing this exact same issue on a NextJS project using BitBucket pipelines.

bitbucket-pipelines.yml (snippet)

  steps:
    - step: &code_quality_scan
        size: 2x
        # clone:
        #   depth: full    # SonarCloud scanner needs the full history to assign issues properly
        name: Analyse code quality with SonarCloud
        # caches:
        #   - sonar
        services:
          - docker
        script:
          - pipe: sonarsource/sonarcloud-scan:1.4.0
            variables:
              SONAR_SCANNER_OPTS: -Xmx7168m
              EXTRA_ARGS: '-Dsonar.sources=. -Dsonar.inclusions=**/*.tsx -Dsonar.javascript.node.maxspace=7168'
          - pipe: sonarsource/sonarcloud-quality-gate:0.1.6
      services:
        docker:
          memory: 7168

SonarCloud output (snippet)

...
INFO: 125/352 files analyzed, current file: /opt/atlassian/pipelines/agent/build/features/x/components/x-view.tsx
INFO: 125/352 files analyzed, current file: /opt/atlassian/pipelines/agent/build/features/x/components/x-view.tsx
INFO: 125/352 files analyzed, current file: /opt/atlassian/pipelines/agent/build/features/x/components/x-view.tsx
INFO: Time spent writing ucfgs 18456ms
ERROR: Failure during analysis, Node.js command to start eslint-bridge was: node --max-old-space-size=7168 /opt/atlassian/pipelines/agent/build/.scannerwork/.sonartmp/eslint-bridge-bundle/package/bin/server 37333 127.0.0.1 /opt/atlassian/pipelines/agent/build/.scannerwork true false /opt/atlassian/pipelines/agent/build/.scannerwork/.sonartmp/eslint-bridge-bundle/package/custom-rules18209903129993414625/package
java.lang.IllegalStateException: eslint-bridge server is not answering
	at org.sonar.plugins.javascript.eslint.AnalysisWithProgram.analyze(AnalysisWithProgram.java:156)
	at org.sonar.plugins.javascript.eslint.AnalysisWithProgram.analyzeProgram(AnalysisWithProgram.java:136)
	at org.sonar.plugins.javascript.eslint.AnalysisWithProgram.analyzeFiles(AnalysisWithProgram.java:93)
...
3

Hi,

Welcome to the community, both of you!

Can one of you share the file analysis stalls on?

 
Thx,
Ann

1 Like
4

Hey, sorry I’m not able to share the source for my project as it is for work but I can tell you that it stalls on completely different files each time as the original poster also mentioned. The files it has stalled on aren’t excessive in terms on lines of code, we’re talking 100-200 lines. Hope that helps but sorry can’t provide much more here.

5

This is correct - I’ve seen 5 to 10 different files - it’s like an external resource (RAM?) is running out - and the file in question is just the file that it’s reading ‘when it happens’. As it happens - the file it choked on in the example I posted was actually a placeholder fuction - it was 7 lines long - and all 7 were comment out.

6

Hi,

Sorry, I misread the OP. I thought it was always stopping on the same file.

So this sounds like a question of resources on your BB build agent.

This might help:

 
Ann

7

Hi Ann,

Thanks for the response - unfortunately, as you can see from my original post - and Adam’s follow up - we’ve tried that option, both at the top and bottom of the range (256 and 7168).

The other option I’ve tried is sonar.javascript.node.maxspace=7168 (with various numbers from 1Gb to 7Gb) - and although it seems to help get further - we still crash out regularly with the ESLint error.

Splitting it up into sub directories (using the monorepo option) helps a bit (in that at least 50% of our code base now scans cleanly) but we are still hitting issues with some directories blowing the memory limit. I’m wondering if the software is memory leaking - or whether we just need to disable this particular check - as it seems to be intensely greedy?

9

Hi,

I’ve flagged this for more expert attention.

 
Ann

2 Likes
11

Hey Ann, I’ve reached the end of my trial so I’ve had to stop my testing. It would be great if I could get a fresh trial once we’ve established a resolution, hope that is possible! All the best, Adam

12

hi @morph42 ,

thanks for reporting this issue, I will try to help to troubleshoot it.

How did it go with monorepo approach? Did you have the same failure? I would expect this to work better for bigger projects.

Could you please post full debug logs? (you can do it also privately if you are concerned about exposing details from your project)

1 Like
13

Hi Tibor,

Thanks for the response… the monorepo approach half fixed it - in that some directories now scan cleanly - but others are still crashing.

Can you explain how to generate a debug log vs just the normal logging (which I’ve already quoted?) How would I send it to you privately?

14

Hey Tibor - any news on this?

16

weekly nudge :slight_smile:

17

Hey, I gave Codacy a go, it runs externally of bitbucket pipelines and is very fast.

19

Thanks Adam - it may be a tad early to claim victory (and it’ll be a very hollow victory at that!) - but I tried a new tactic.

I installed a Bitbucket Runner in our Kube infrastructure - which allowed me to double up the maximum resources available to Sonarscan (4x rather than 2x). When running in this configuration - it has succeeded without error three times in a row… so I’m suspecting it’s a pure resource management issue in eslint-bridge - and ‘throwing enough metal’ does work - but this is a very unsatisfactory solution.

@saberduck - I’m still around if you want to debug it further.

20

A little extra update. We setup another project for a very simple Angular framework.

  • No monorepo
  • No big files
  • Only 22 JS files in the scan.

SonarScan takes 20+ minutes before crashing out. The file it seems to dwell on is random everytime - but an example is environment.template.js - which is a 16 line file so simple even I can scan it :wink:

I think default SonarScan is broken for JS files on Bitbucket atm - is there a way I can raise an official bug about it to get looked at?

21

Hello @morph42 @AB2022,

Seems some users with a similar issue fixed this by setting sonar.typescript.tsconfigPaths with the root tsconfig.json of the project. Can you please check if that helps in your case also?

Cheers,
Victor

24

Hi @victor.diez,

Thanks for the response. We did add that but it didn’t seem to help with our issue - the tests still stopped randomly. One of our senior Devs made it their mission to help - and we ended up with this:

sonar.typescript.tsconfigPaths=tsconfig.json

sonar.organization=${ORG}
sonar.projectKey=${KEY}
sonar.projectName=${NAME}

sonar.language=ts

sonar.sources=src
sonar.tests=src

sonar.exclusions=dist,**/node_modules/**,src/main.ts,**/*.{spec,story,stories}.{js,ts},**/*.template.js
sonar.test.inclusions=**/*.{spec,story,stories}.{js,ts}

sonar.javascript.lcov.reportPaths=reports/coverage/lcov.info
sonar.testExecutionReportPaths=reports/sonar-report.xml

This ran in 3 minutes for the new Angular site for a period of time - so we all celebrated a job well done - but since then small changes to the code base have now pushed us back to docker out of memory errors and 30 minute runtimes with random pauses.

It feels to me that SonarScan and JS just isn’t a good combo at the moment - which is a massive shame as we love using it on PHP projects.

25

Hi @morph42,

We are aware of these performance issues and we are currently working to fix them.

In the meantime, does your base tsconfig.json specify includes or files? If so, can you create a tsconfig.sonar.json to be used for the analysis? It should contain the same compilerOptions as your base tsconfig.json, but without those includes or files specified.

As for memory, I understand you increased already memory for docker?

      services:
        docker:
          memory: 7168

Again, thanks for your feedback. We’ll try to have a new release done soon.

Cheers,
Victor

28

We are also facing this issue using SonarQube Developer Edition and Bitbucket Cloud pipelines on a fairly large Next.js TypeScript project. We have tried most the fixes mentioned here with no luck. We have other TypeScript and Javascript projects that are working. Following for any updates.