ci: add SonarCloud continuous inspection

[don-petry]

Why?

SonarCloud provides continuous code quality inspection — tracking bugs, code smells, security vulnerabilities, and test coverage over time. Unlike one-shot linters, it maintains a historical baseline so quality trends are visible and regressions are caught as they happen.

Summary

• Adds sonar-project.properties with project configuration for SonarCloud
• Adds .github/workflows/sonarcloud.yml GitHub Actions workflow that runs SonarCloud analysis on pushes to main and on pull requests
• Fork PRs are handled gracefully — the scan step is skipped when SONAR_TOKEN is unavailable

Relates to #11 (item 9 — SonarCloud / SonarQube integration).

Maintainer setup required

1. Create a SonarCloud account at sonarcloud.io and import the oneirosoft/dagger repository
2. Add the SONAR_TOKEN secret to the GitHub repository settings (Settings → Secrets and variables → Actions → New repository secret)

Test plan

• Verify the workflow triggers on push to main and on PRs
• Confirm SonarCloud scan completes successfully once the token is configured

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds SonarCloud continuous inspection to the repository by introducing a standard SonarCloud project configuration file and a dedicated GitHub Actions workflow to run scans on main and on pull requests.

Changes:

• Add sonar-project.properties to define SonarCloud project/org and analysis scope.
• Add .github/workflows/sonarcloud.yml to run SonarCloud analysis in CI on pushes to main and PR updates.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
sonar-project.properties	Defines SonarCloud project settings and what paths to analyze/exclude.
.github/workflows/sonarcloud.yml	Introduces a CI workflow job to execute the SonarCloud scan action.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

sonar.tests=tests won’t classify the repo’s unit test files under src/core/**/tests.rs as tests, so SonarCloud will analyze them as production sources and skew metrics (bugs/smells/coverage on “new code”). Consider either adding those paths via sonar.tests + sonar.test.inclusions (e.g., matching src/**/tests.rs) or excluding src/**/tests.rs from sonar.sources using sonar.exclusions.

Suggested change

	sonar.exclusions=**/test_support.rs
	sonar.exclusions=**/test_support.rs
	sonar.test.inclusions=src/**/tests.rs

[don-petry]

Addressed — removed sonar.tests since Rust unit tests live alongside source code in #[cfg(test)] modules, not in a separate directory.

[Copilot]

This workflow will fail on pull requests from forks because secrets.SONAR_TOKEN is not provided for forked PRs, causing the scan step to error and the PR check to go red. To avoid blocking external contributors, add a job/step if: guard to only run when the PR originates from the same repo (or when secrets.SONAR_TOKEN is set), or make the scan non-blocking for forked PRs.

[don-petry]

The if: ${{ env.SONAR_TOKEN \!= '' }} guard on the scan step already handles this — when the secret is unavailable on fork PRs, the step is skipped and the job succeeds. This matches the pattern used across all petry-projects repos.