# Run SonarQube static analysis against the code that just landed on `main` and # report the results to the self-hosted SonarQube server for review. This is # intentionally NON-BLOCKING: it triggers on push to main (i.e. AFTER merge), # not on pull_request, so it never gates a PR. It complements release.yml # (which builds + cuts releases) — this one only feeds the dashboard. # # Prerequisites (one-time, in the Gitea UI — Repo → Settings → Actions): # • Secret SONAR_TOKEN — a SonarQube "Analysis" token generated at # My Account → Security in SonarQube for the # Runic-Gateway-link project (or a global one). # • Variable SONAR_HOST_URL — the SonarQube base URL on your LAN, e.g. # http://192.168.0.56:9000 # (kept as a variable, not committed, so the internal address stays out of git.) # # The runner (self-hosted `ubuntu-latest`, same as release.yml) must be able to # reach SONAR_HOST_URL on your network. Nothing here waits on the SonarQube # Quality Gate, so a failing gate does not fail this job — check the dashboard # when you want to. # # Scope: this analyses the Rust source directly (the Sonar scanner reads # sonar-project.properties). It does NOT build the crate or run Clippy — see the # "Optional enrichment" note in sonar-project.properties for wiring in a Clippy # report if your SonarQube edition supports Rust lint import. name: SonarQube on: push: branches: [main] # Allow re-running the analysis on demand from the Actions tab. workflow_dispatch: {} concurrency: group: sonarqube-${{ github.ref }} cancel-in-progress: true jobs: analysis: runs-on: ubuntu-latest steps: - name: Check out (full history for accurate new-code + blame) uses: actions/checkout@v4 with: # SonarQube uses git history to attribute issues to authors and to # compute "new code". A shallow clone degrades both. fetch-depth: 0 - name: Run SonarQube scan uses: sonarsource/sonarqube-scan-action@v4 env: SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}