SonarCloud

SonarCloud is our primary quality gate tool. It checks for each of the following:

• Issues (previously called code smells)
• Duplication
• Coverage
• Security hotspots

A passing SonarCloud analysis is required as a milestone on all PRs before they can be merged.

SonarCloud will run automatically (via Github actions) on all PRs that are from internal contributions (branches in the repo). SonarCloud will not run on PRs that come from external contributions (forked branch PRs).

SonarCloud on forked branch PRs

A forked branch PR can edit anything in the code base. This includes the Github action workflow files. This means that they could add things like echo "${SONAR_TOKEN}" to print the SonarCloud token to the console.

Because anyone can fork the repository and submit a PR, Github does not allow access to any of the tokens or secrets on actions that are triggered from forked branch PR.

SonarCloud requires the SONAR_TOKEN to authenticate the project. Because of this, Sonar Cloud cannot run on forked branch PRs. Unfortunately, this is when we want the SonarCloud analysis the most!

So what do we do?

The solution to this is to trigger the analysis manually on your local machine. Once your machine is setup (see instructions below), all you need to do is run the following:

yarn sonar-fork-pr <pr-number>

This will install dependencies, run tests and execute the SonarCloud analysis. When complete, a full report will be available in the SonarCloud project and the SonarBot will upload the results summary to the PR and mark the sonar check as passed or failed.

Set up my machine to be able to run the SonarCloud analysis

All of the following steps only need to be done once except for the Github token which you'll need to refresh whenever it expires (you set the expiration).

Install the SonarScanner app

1. Go to this page and sign in
2. For "What option best describes your project", select "Other (for JS, TS, Go, Python, PHP, ...)"
3. For "Which OS do you run your build on?", select the operating system of your computer (macOS)
4. Select Download
5. Unzip the downloaded folder and move it to your root folder ~
6. In a terminal, navigate to the new sonar-scanner folder and then navigate into the /bin folder
   • cd ~/sonar-scanner-6.2.1.4610-macosx-x64/bin (on my machine)
7. Print out the current path by running pwd and copy the full path
8. Add this export to your .zshrc, export PATH="MY_COPIED_PATH:$PATH", where MY_COPIED_PATH is the path you copied to the clipboard on the previous step. A quick way to do this is with echo "export PATH="MY_COPIED_PATH:$PATH"" >> ~/.zshrc
9. Run source ~/.zshrc to apply the changes
10. Verify that sonar-scanner is working by running sonar-scanner -h in your new terminal

Setup your local.json

1. Add a file to the react-spectrum-charts/ folder called local.json
2. Paste the following contents into local.json

   {
        "SONAR_TOKEN": "",
        "GITHUB_TOKEN": ""
    }
   

SONAR_TOKEN

1. Return to this page and copy the value of the sonar token
2. Paste the copied token into the local.json as the "SONAR_TOKEN"

GITHUB_TOKEN

1. Go to Github settings
2. Select "Developer settings" form the left navigation
3. Select "Personal access tokens" > "Fine-grained tokens"
4. Select "Generate new token"
5. Give the token a name (ex. read-only-token)
6. Make sure you are the "Resource owner"
7. Set the expiration (90 days is recommended)
8. Leave access as "Public Repositories (read-only)"
9. Generate the token
10. Copy the generated token and paste it into you local.json as the "GITHUB_TOKEN"

NOTE: You will need to redo this step whenever your GITHUB_TOKEN expires.

Try it out!

Pull in a branch that currently has an open PR for it and run yarn sonar. This will run all tests and then execute the sonar analysis.

Appendix

When I (@marshallpete) first ran into the issue where forked branch PRs cannot access the SONAR_TOKEN, I tried a workaround where we break the CI pipeline into two steps. The first just installs dependencies, builds, tests and then uploads the test coverage to an artifact.

This would trigger a second action that would checkout the PR code, download the artifacts and use them to run the SonarCloud analysis.

This worked because when you trigger an action off of the completion of another, it runs in the context of our repo. This means it has access to secrets and tokens and therefore can execute the SonarCloud analysis.

The problem with this is it opened the repository up to a couple of vulnerabilities.

A forked branch PR could modify the original build action and upload whatever artifacts they wanted. Then in the follow-up action, when these artifacts get downloaded, they could have malicious content in them, like bash scripts. This means a bad actor could run whatever bash scripts they wanted with full access to tokens and secrets.

This is why we killed the follow up actions and have instead have implemented this method. By pulling the code into your own machine and manually triggering the analysis, there is no possibility of malicious code running.