chore: remove SonarQube integration from CI

[Copilot]

Removes all SonarQube integration from the repository after repeated attempts to make it work with Nix build-sandbox paths and the Nix gcc-wrapper failed.

Changes Made

• Removed sonar-project.properties from the repository root
• Removed the "Fix compile_commands.json paths" CI workflow step (Python script that patched compile_commands.json for SonarQube compatibility)
• Removed the "SonarQube Scan" CI workflow step from .github/workflows/ci-linux.yml

The CI workflow now only runs the Nix build, test, coverage check, and Codacy coverage reporting steps.

[FreeYourSoul]

@copilot I think you need to copy the file first before modifying it (permission denied)

[Copilot]

@copilot I think you need to copy the file first before modifying it (permission denied)

Good catch. The result/ symlink points into the Nix store which is read-only (444 permissions), and cp was preserving those permissions, causing the Python write to fail. Fixed in f0fd63f by using cp --no-preserve=mode so the copied file gets normal writable permissions.

[FreeYourSoul]

@copilot Still not ok, the replace looks like to have worked though, but sonarqube is still not working

[Copilot]

@copilot Still not ok, the replace looks like to have worked though, but sonarqube is still not working

The source path replacement was working correctly, but the command field in compile_commands.json was using the Nix gcc-wrapper (/nix/store/.../gcc-wrapper-15.2.0/bin/g++), which is a shell script wrapper rather than a real compiler binary. SonarQube CFamily doesn't support it and marks all compilation units as "unsupported."

Fixed in 4356cd3: after replacing source paths, the script now also replaces any /nix/store/.../bin/<compiler> paths in the command field with the bare compiler name (e.g. g++), which resolves to the system compiler that SonarQube can recognize.

[FreeYourSoul]

@copilot still didn't work

[Copilot]

@copilot still didn't work

Looking at the latest CI logs, both the source-path and compiler-wrapper replacements were working correctly. The remaining issue was -std=gnu++26 in the command field — SonarQube CFamily 6.x only supports up to C++23 and classifies any compilation unit using an unrecognised standard as "unsupported".

Fixed in f2831e0: the script now also normalises the C++ standard flag — stripping the gnu extension prefix and capping the version at 23 (e.g. -std=gnu++26 → -std=c++23).

[FreeYourSoul]

I give up on using sonar, can you remove the code that is triggering sonar (the porperty file) etc.. ?

[FreeYourSoul]

@copilot I give up on using sonar, can you remove the code that is triggering sonar (the porperty file) etc.. ?

[Copilot]

@copilot I give up on using sonar, can you remove the code that is triggering sonar (the porperty file) etc.. ?

Done in e0f9454 — removed sonar-project.properties and deleted the "Fix compile_commands.json paths" and "SonarQube Scan" steps from the CI workflow.

[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