ci/sonarcloud

[diazdesandi]

What does this PR do?

This pull request integrates SonarCloud analysis into the CI pipeline.

PR Type

• CI/CD related changes
• Code style update (formatting, renaming)

Does this PR introduce a breaking change?

• No

What is the current behavior?

SonarCloud analysis is not integrated into the CI workflow. Code style inconsistencies may exist across the codebase.

What is the new behavior?

Adds SonarCloud analysis to the CI pipeline.

Other information

SonarQube Cloud is free for OSS projects. I believe it could be a good addition. The org would need to be created here and update the contents of sonar-project.properties with the defined values as well as the GitHub Secret.

Plans & Pricing: AI Code Verification at Scale | Sonar

Summary by CodeRabbit

• Chores
  • Added CI configuration and project settings to enable SonarQube analysis for pull requests and manual runs, improving code quality tracking and reporting.

[stonerl]

I'll have a look over the weekend into SonarQube Cloude over the weekend. Thanks for the PR

[diazdesandi]

It has a feature called Architecture that lets you visualize how code components relate and depend on each other. You can also define the intended architecture in a YAML or JSON file and SonarCloud will then flag deviations from it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7453d51b-0ece-448f-9f48-09376720d8bb

📥 Commits

Reviewing files that changed from the base of the PR and between 9cb652e and 3e1268d.

📒 Files selected for processing (1)

• sonar-project.properties

🚧 Files skipped from review as they are similar to previous changes (1)

• sonar-project.properties

---

📝 Walkthrough

Walkthrough

Adds SonarQube analysis: a new GitHub Actions workflow (.github/workflows/sonarcloud.yml) that runs SonarQube scans on PR events (opened, synchronize, reopened) and manual dispatch, plus a sonar-project.properties file declaring project metadata, sources, and exclusion patterns.

Changes

Cohort / File(s)	Summary
CI workflow .github/workflows/sonarcloud.yml	Adds a new GitHub Actions workflow triggered on pull_request (opened, synchronize, reopened) and workflow_dispatch; defines SONAR_TOKEN from secrets; job sonarqube runs on macos-latest, restricts fork runs, checks out repo with fetch-depth: 0, and invokes SonarSource/sonarqube-scan-action (specific commit-ish).
Sonar config sonar-project.properties	Adds SonarQube project config: sonar.projectKey=stonerl_Thaw, sonar.organization=stonerl, sonar.projectName=Thaw, sonar.projectVersion=1.1.0, sonar.sources=Thaw,Shared,MenuBarItemService, exclusions for images/assets (**/*.png,**/*.pdf,**/*.xcassets/**,**/*.imageset/**), and sonar.sourceEncoding=UTF-8.

Sequence Diagram(s)

sequenceDiagram
  participant PR as "GitHub PR"
  participant Actions as "GitHub Actions Runner"
  participant Repo as "Repository (checkout)"
  participant Sonar as "SonarCloud/Scanner"

  PR->>Actions: open / synchronize / reopen / workflow_dispatch
  Actions->>Repo: checkout (fetch-depth: 0)
  Actions->>Sonar: run SonarSource/sonarqube-scan-action (uses SONAR_TOKEN)
  Sonar-->>Actions: return analysis results
  Actions-->>PR: post status / annotations

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I hopped into CI with a tiny tap,
A Sonar sniff across each app and map,
From Thaw to Shared I pranced and peered,
Chasing warnings that once appeared,
🥕🔍

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'ci/sonarcloud' is vague and abbreviated, using a branch-naming convention rather than describing the actual change in human-readable terms.	Use a descriptive title like 'Add SonarCloud analysis to CI pipeline' that clearly explains what is being added or changed.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The PR description covers the main objectives and includes most key sections (What does this PR do, PR Type, Breaking changes, Current/New behavior), fulfilling the essential documentation requirements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

.github/workflows/sonarcloud.yml (2)

1-5: Consider adding a push trigger for the main branch.

SonarCloud PR analysis relies on comparing against a baseline from the default branch. Without running analysis on pushes to main, the PR decoration and new code detection may not function correctly.

♻️ Proposed fix to add push trigger

 name: SonarQube Analysis
 on:
+    push:
+        branches:
+            - main
     pull_request:
         types: [opened, synchronize, reopened]
     workflow_dispatch:

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/sonarcloud.yml around lines 1 - 5, The workflow "SonarQube
Analysis" currently triggers only on pull_request and workflow_dispatch; add a
push trigger so SonarCloud runs on pushes to the default branch (main) to
produce a baseline for PR decoration. Update the workflow triggers to include a
push block with branches: [main] alongside the existing pull_request and
workflow_dispatch entries (i.e., add a "push:" entry under "on:" in the
SonarQube Analysis workflow).

---

7-8: Consider scoping SONAR_TOKEN to the step level.

While workflow-level environment variables work, scoping secrets to the specific step that needs them follows the principle of least privilege and reduces exposure surface.

♻️ Proposed refactor to scope token to step

-env:
-    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
 jobs:
     sonarqube:
         if: github.repository == 'stonerl/Thaw' # Only run on the main repository, not on forks
         runs-on: macos-latest
         steps:
             - uses: actions/checkout@v5
               with:
                   fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
             - name: SonarQube Scan
               uses: SonarSource/sonarqube-scan-action@a31c9398be7ace6bbfaf30c0bd5d415f843d45e9
+              env:
+                  SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/sonarcloud.yml around lines 7 - 8, The SONAR_TOKEN
currently declared under the workflow-level env should be moved to the specific
job step that runs SonarCloud analysis to reduce secret exposure; locate the
step that invokes the SonarCloud scanner (the step that uses SONAR_TOKEN / the
SonarCloud scan step) and remove SONAR_TOKEN from the top-level env, then add
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} under that step's env block so only that
step has access to the secret.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/sonarcloud.yml:
- Around line 1-5: The workflow "SonarQube Analysis" currently triggers only on
pull_request and workflow_dispatch; add a push trigger so SonarCloud runs on
pushes to the default branch (main) to produce a baseline for PR decoration.
Update the workflow triggers to include a push block with branches: [main]
alongside the existing pull_request and workflow_dispatch entries (i.e., add a
"push:" entry under "on:" in the SonarQube Analysis workflow).
- Around line 7-8: The SONAR_TOKEN currently declared under the workflow-level
env should be moved to the specific job step that runs SonarCloud analysis to
reduce secret exposure; locate the step that invokes the SonarCloud scanner (the
step that uses SONAR_TOKEN / the SonarCloud scan step) and remove SONAR_TOKEN
from the top-level env, then add SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} under
that step's env block so only that step has access to the secret.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ef8dd3e9-6116-4e4a-a2b5-eeb2d9224187

📥 Commits

Reviewing files that changed from the base of the PR and between 3c54f55 and e5a5c1b.

📒 Files selected for processing (2)

• .github/workflows/sonarcloud.yml
• sonar-project.properties

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[stonerl]

 Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator to check the permissions of the user the token belongs to

[diazdesandi]

@stonerl for this error these are the fixes. In the project, go to Analysis method, click "with GitHub Actions" and copy the key and put it into the SONAR_TOKEN repository secret.