We are having trouble getting SonarCloud to resolve paths in our test coverage reports. We’re using GitHub and GitHub Actions for a TypeScript application with Jest tests. Sonar scans are running using the official SonarCloud Action. We’re able to generate an LCOV report and the scanner picks it up, but when it tries to resolve the paths within the report it fails. This leaves us without test coverage information.
This seems to be similar to the issue encountered here: Sonarcloud-github-action coverage percentage missing from sonar cloud - #6 by Colin
I can share the YAML we’re using for the Sonar-related job in Actions, but it’s not doing anything out of the ordinary so I’ll leave it out for brevity.
This is the error generated:
INFO: Analysing [/github/workspace/__tests__/results/lcov.info]
WARN: Could not resolve 1 file paths in [/github/workspace/__tests__/results/lcov.info]
WARN: First unresolved path: assets/Redacted.js (Run in DEBUG mode to get full list of unresolved paths)
This is potentially related to a GitHub Actions bug: https://github.com/actions/runner/issues/2058. The issue seems to be that the Sonar scanner action runs in an isolated workspace; it has this information during runs:
INFO: Base dir: /github/workspace
INFO: Working dir: /github/workspace/.scannerwork
This is potentially the problem because the rest of the workflow runs in /home/runner/work/reponame/reponame. I would think we could work around this problem by adjusting the projectBaseDir using either sonar-project.properties or the parameter in the scanner action. However, neither of those seem to be effective; the base dir is always reported as /github/workspace.
Is the official Sonar scanner Action meant to run in a separate workspace or is this a side effect of the GitHub Actions bug related to container-based jobs?
Somewhat related: should we be able to use projectBaseDir to ensure paths are resolvable? Is that working as intended given the action’s behavior?
1 Like
I kept digging and found some open issues that seem related to this:
That makes it seem like the workspace difference is the problem and can be worked around by converting the LCOV report’s paths to relative ones instead of absolute. However, the paths in our LCOV file are already relative. I also tried adding absolute paths within the container workspace (i.e. adding /github/workspace/ to the beginning of the file path) but that still ended up with essentially the same result:
INFO: Analysing [/github/workspace/__tests__/results/lcov.info]
WARN: Could not resolve 1 file paths in [/github/workspace/__tests__/results/lcov.info]
WARN: First unresolved path: /github/workspace/assets/Redacted.js (Run in DEBUG mode to get full list of unresolved paths)
Hi @edamonoomph ,
I am sorry for the long delay in contacting you about this issue. I would like to see if I can assist in resolving the problem. Firstly can I check if you are still experiencing this issue? I see that you have tried both relative and absolute paths for this. Can I ask how your project is setup in general? you have mentioned that the the working paths and the coverage are in different workspaces, can you clarify the structure of the project? I would like to see if I can create a similar project structure on my side to test this and see if we can identify a fix for you.
Hi Shane, yes we are still experiencing this issue.
To clarify the workspace difference, I’m referring to the “workspace” as used by GitHub Actions, not the structure of the project. The project is a very typical TypeScript project using Jest for tests. It’s being built and deployed using AWS SAM; I don’t think that makes a functional difference but in terms of getting a similar project set up something like this should be very similar: Building TypeScript projects with AWS SAM CLI | AWS Compute Blog. The Actions steps we have in the workflow don’t do anything out of the ordinary, essentially:
npm installnpm run test (Jest)npm prune --productionsam build- Run SonarCloud scan with official action: GitHub - SonarSource/sonarcloud-github-action: Integrate SonarCloud code analysis to GitHub Actions
The workspace issue seems to be a GitHub Actions problem. The “workspace” is just where the Actions workflow steps are performed. The problem is due to an inconsistency: when a step is run normally the workspace is in one location, but when a step uses a container-based action then workspace is in a different location. From what I can tell this is causing Sonar to be unable to find required files because the action is configured to run in a container, which means it runs in a different workspace than the rest of the workflow.
Thank you for the information @edamonoomph, I will try and recreate the issue on our side and come back to you with some information.