
Now, lets see the steps that you need to do in the test step of your build pipeline:
The deploy step may or may not exist for you depending on your CI/CD setup. The test step is the place where you want to trigger your Playwright tests on the BrowserStack infra. The build step should comprise of building your application and making sure that it is hosted in some staging/equivalent environment and ready to be tested. Generic steps to follow for triggering Playwright tests from any CI/CD toolĮvery CI/CD pipeline/tool allows to specify build, test and/or deploy steps as follows: I don’t like littering that directory with unrelated files, so I added this to the end of my package.json file in order to put the report in a reports directory.Check out our official CI/CD plugins here: The first thing to note is that we use the property in our sonar-project.js configuration, not the javascript property.īy default jest-sonar-reporter outputs a file called test-report.xml to the root directory. sonar.testExecutionReportPaths is the path to the jest-sonar-reporter output file.
is the path to the test coverage output file from jest. ts tests, but they all follow the standard jest pattern of * is a comma separated list of all files that should be treated as test files. By default, CRA puts this in /src/_tests_ sonar.tests is the location of all of your tests. So I exclude anything in any _tests_ folder. In fact, if there is overlap between sonar.sources and sonar.tests then Sonar will throw an indexing error. The most important one for me is that we don’t want to be analysis on our tests. sonar.exclusions is everything you do not want Sonar to analyze. By default, CRA puts _tests_ within the src directory. This is where your React application lives (in my case the *.tsx files). sonar.sources is the base directory for all of your code. token is the security token assigned to your Sonar user. serverUrl is the URL to your SonarQube instance. "sonar.testExecutionReportPaths": "reports/test-report.xml",Įach of these settings is a standard Sonar configuration property, but they weren’t immediately clear to me. const sonarqubeScanner = require("sonarqube-scanner") In the root of your project (at the same level as your package.json) create a file named sonar-project.js with the following contents. I was expecting to do a bunch of configuration within Sonar itself, but it can all be contained within your React project. Yarn add -D jest-sonar-reporter Sonar Configuration
JEST TEAMCITY REPORTER INSTALL
Install sonarqube-scanner and jest-sonar-reporter into your React project using either yarn or npm. You’ll need a couple tools to simplify this process. Analyzing your React application with Sonar Tools If not, you can always do so in Administration > Security and creating a Sonar user just for project analysis (this is probably a good idea anyway). There should be a wizard that guides you through creating a security token for your user.
This will start a SonarQube instance using Postgres on Open that URL in a browser, log in with admin/admin, and make sure everything is looking good. Next, I used this docker-compose file from. I used Docker for this because it was the quickest way.įirst, set your memory allocation for Docker to at least 4GB for the Sonar container to be able to run correctly. I’m also assuming you’re comfortable with Docker. For example if you cannot successfully run npm test or yarn test then this guide will not work. Your mileage may vary.įirst of all, I’m going to assume nothing is ejected from the CRA configuration and that you have a working application written in TypeScript. These are the versions of the different components I’m using. This article was written in February, 2020. Turns out that it’s not that hard once you know all the pieces that need to be pulled together. There are a ton of posts on StackOverflow and Medium and the rest of the internet on setting up SonarQube, but I couldn’t find a definitive guide on configuring it with a React web application (using react-scripts/ create react app) written in TypeScript.