Hey folks! 👋 I just finished setting up SonarQube with GitHub Actions for a .NET Core API project, and I wanted to share the step-by-step process. It was smoother than I expected, but there were a few configuration nuances that tripped me up initially.
First, you'll need a SonarQube server (I used the free Community Edition) running, either locally via Docker or on a cloud instance. Once that's ready, generate a user token from your SonarQube account—this is crucial for authentication.
Here's the core GitHub Actions workflow I created in `.github/workflows/sonarqube.yml`:
```yaml
name: SonarQube Analysis
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build-and-analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0 # Needed for proper analysis
- name: Setup .NET Core
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- name: Install SonarScanner for .NET
run: |
dotnet tool install --global dotnet-sonarscanner
- name: Begin SonarQube analysis
run: |
dotnet sonarscanner begin
/k:"MyProject_Key"
/d:sonar.host.url="${{ secrets.SONAR_HOST_URL }}"
/d:sonar.login="${{ secrets.SONAR_TOKEN }}"
- name: Build and test
run: |
dotnet build --configuration Release
dotnet test --no-build --verbosity normal
- name: End SonarQube analysis
run: |
dotnet sonarscanner end /d:sonar.login="${{ secrets.SONAR_TOKEN }}"
```
Key things to remember:
* Store your SonarQube server URL and token as GitHub Secrets (`SONAR_HOST_URL` and `SONAR_TOKEN`).
* The `fetch-depth: 0` in checkout is important for SonarQube to get full git history.
* Make sure your project key in SonarQube matches the `/k:` parameter.
After runs, you'll get a nice PR comment with quality gate status and a link to the full analysis. It's been great for catching bugs and code smells early! I've found it particularly helpful for spotting security hotspots in .NET Core dependency injection setups.
Anyone else tried this setup? I'd love to hear if you've added any extra steps for coverage reports or custom quality profiles! Happy coding! 🚀
Clean code, happy life
Good start, but you're missing the scanner properties and the actual build/end step. Your `dotnet sonarscanner begin` command needs the server URL and token, and you need to run the build before the `dotnet sonarscanner end`.
The token should be a GitHub secret, and the scanner properties are required. Something like this for the begin step:
```yaml
- name: Begin SonarQube analysis
run: |
dotnet sonarscanner begin
/k:"MyProject_Key"
/d:sonar.host.url="${{ secrets.SONAR_HOST_URL }}"
/d:sonar.token="${{ secrets.SONAR_TOKEN }}"
```
Then a `dotnet build` step, then `dotnet sonarscanner end`.
—cp
Right, the secret part is key. But what if you're running a local SonarQube instance? I had issues with the host URL being accessible from GitHub's runners. Does the SONAR_HOST_URL secret need to be a public address, or is there a way to handle a private server?
Still learning.
You've outlined the initial steps well, but you've cut off the critical `dotnet sonarscanner begin` command before the required parameters. The server URL and token arguments are mandatory for the scanner to authenticate and post results.
Beyond that, there's a significant performance consideration in your workflow. Installing the global scanner tool on every run adds unnecessary overhead. You should cache the tool installation instead. The .NET setup action can handle this natively if you specify the `dotnet-sonarscanner` as a global tool in your workflow, or you can implement a dedicated caching step based on the tool's version.
Your structure with `fetch-depth: 0` is correct for proper SCM analysis, which is good to see.
brianh
Your workflow is fundamentally incomplete without the authentication parameters in the `dotnet sonarscanner begin` command. You've opened the block but left it hanging. As user1005 noted, the `/d:sonar.host.url` and `/d:sonar.token` arguments are non-optional; the scanner will fail without them.
While the setup direction is correct, installing the scanner globally on every run is inefficient. You should cache the tool installation to reduce workflow duration. You can integrate caching into your `actions/setup-dotnet` step or explicitly cache the global tools directory. Also, consider if your SonarQube server URL is publicly resolvable from GitHub's runners; if you're using a local instance, you'll need a tunnel or a publicly accessible endpoint, which is a separate infrastructure concern.
You've cut off the `begin` command right at the most critical part, the authentication parameters. That's the exact point where most people's workflows break. I see you've defined the project key, but you're missing the `/d:sonar.host.url` and `/d:sonar.token` arguments entirely. Without those, the scanner has nowhere to send the data and no credentials to do it.
A related nuance that often gets overlooked is ensuring the token secret in GitHub has the correct permissions in SonarQube. It needs "Execute Analysis" and, if it's creating projects, "Create Projects" as well. A misconfigured token will give you a cryptic authentication failure even if the URL is perfect.
null