sonar: correct the project key, and record what the first run measured

Conversation 1 Commits 1 Files Changed 2

+37 -17

1 Commits

Author	SHA1	Message	Date
jklein	f284d209f7	sonar: correct the project key, and record what the first run measured Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s Details Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Skipped Details Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Skipped Details Validate Helm Charts / Install-test (pull_request) Skipped Details Validate Helm Charts / Resource quantities (pull_request) Successful in 9s Details SonarQube Analysis / SonarQube Analysis (push) Successful in 42s Details The project key was a guess. The project exists in SonarQube as JLab-Helm-Charts; jlab-cluster_helm-charts was reasoned from the instance serving two owners, and it produced the one error message that covers both a non-existent project and a token without permission on it: ERROR You're not authorized to analyze this project or the project doesn't exist on SonarQube and you're not authorized to create it. Because the server does not distinguish those two cases, the next occurrence of that message now means the token lacks "Execute Analysis" - which is worth a comment in the file rather than a second round of guessing. sonar.projectName goes away entirely. Once the project exists on the server the display name belongs to the server, and a name sent with every analysis would overwrite a rename there on every run, silently. The reason is a comment in the file so the line is not added back as an obvious omission. The README analyser table was built from SonarQube's language list and promised more than this instance delivers. Measured in run 375: two quality profiles loaded, json and yaml; the IaC Kubernetes sensor (3.4 s) and the secrets detection over all 391 indexed files did the work. Shell and GitHub Actions did not run, and no configuration here can make them - analysers are server-side plugins. The consequence is now stated: the five ci/ scripts and the thirty workflow files, the files carrying the actual logic, are not analysed at all. Whether the instance gains those plugins is a decision outside this repository. Run 375 also answered the three questions this path carried, all positively: node24 is in the runner image, the ~59 MiB scanner download and its signature arrived in roughly three seconds (so the MTU failure that once killed a 17 MB download does not repeat), and a repository variable does reach a workflow called from another repository - which settles the identical question the publish route carried for OP_CONNECT_HOST. The publish route's upload is still unproven and stays listed as such. Fixes #74	2026-10-02 00:15:06 +00:00

Author

SHA1

Message

Date

jklein

f284d209f7

sonar: correct the project key, and record what the first run measured

Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s

Details

Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Skipped

Details

Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Skipped

Details

Validate Helm Charts / Install-test (pull_request) Skipped

Details

Validate Helm Charts / Resource quantities (pull_request) Successful in 9s

Details

SonarQube Analysis / SonarQube Analysis (push) Successful in 42s

Details

The project key was a guess. The project exists in SonarQube as
JLab-Helm-Charts; jlab-cluster_helm-charts was reasoned from the instance
serving two owners, and it produced the one error message that covers both a
non-existent project and a token without permission on it:

  ERROR You're not authorized to analyze this project or the project doesn't
        exist on SonarQube and you're not authorized to create it.

Because the server does not distinguish those two cases, the next occurrence of
that message now means the token lacks "Execute Analysis" - which is worth a
comment in the file rather than a second round of guessing.

sonar.projectName goes away entirely. Once the project exists on the server the
display name belongs to the server, and a name sent with every analysis would
overwrite a rename there on every run, silently. The reason is a comment in the
file so the line is not added back as an obvious omission.

The README analyser table was built from SonarQube's language list and promised
more than this instance delivers. Measured in run 375: two quality profiles
loaded, json and yaml; the IaC Kubernetes sensor (3.4 s) and the secrets
detection over all 391 indexed files did the work. Shell and GitHub Actions did
not run, and no configuration here can make them - analysers are server-side
plugins. The consequence is now stated: the five ci/ scripts and the thirty
workflow files, the files carrying the actual logic, are not analysed at all.
Whether the instance gains those plugins is a decision outside this repository.

Run 375 also answered the three questions this path carried, all positively:
node24 is in the runner image, the ~59 MiB scanner download and its signature
arrived in roughly three seconds (so the MTU failure that once killed a 17 MB
download does not repeat), and a repository variable does reach a workflow
called from another repository - which settles the identical question the
publish route carried for OP_CONNECT_HOST. The publish route's upload is still
unproven and stays listed as such.

Fixes #74

2026-10-02 00:15:06 +00:00

sonar: correct the project key, and record what the first run measured #75