sonar: correct the project key, and record what the first run measured #75
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#75
Reference in new issue
Block a user
Fixes #74
The key was a guess, and the server has the real one
sonar.projectKeybecomesJLab-Helm-Charts— the key the project already has in SonarQube, given by the maintainer. The previous value,jlab-cluster_helm-charts, was reasoned from the instance serving two owners rather than read off the server, and it produced exactly the error a non-existent project produces:That message covers two different causes and the server does not distinguish them. Which is why the file now says so: with the key known to be right, the same message next time means the token lacks "Execute Analysis" on that project, and nobody should spend a second round guessing at the key.
sonar.projectNameis removed, not correctedOnce the project exists on the server, the display name belongs to the server. A name sent along with the analysis overwrites it on every run — so a rename made in SonarQube would snap back silently, with nothing failing anywhere to report it. The reasoning sits as a comment in the file, because otherwise the line comes back as an obvious omission.
The analyser table promised more than the instance delivers
The table came from SonarQube's language list. Measured in run 375, the server loaded two quality profiles,
jsonandyaml; the sensors that worked were IaC Kubernetes (3.4 s) and the secrets detection over all 391 indexed files.values.schema.jsonci/No change in this repository can fix the last two rows: analysers are server-side plugins. The scanner downloads a CLI, not a set of languages. The consequence is now written down in README and on the wiki rather than left to be rediscovered — the files carrying the actual logic here, the five
ci/scripts and the thirty workflows, are not analysed at all. What runs is IaC over the charts and secret detection over everything;shellcheckand review stay the only check on the scripts. Whether the instance is upgraded or gains those plugins is a decision for whoever operates SonarQube and is not open work here.Three measurements, all positive
Run 375 was red at the upload, but everything before the upload ran — which is what makes it a measurement:
node24is in the runner image. The JavaScript scan action ran.vars.SONAR_HOST_URL. This settles the identical question the publish route carried forOP_CONNECT_HOST— same forge version, same mechanism — so no second measurement is needed there and the fallback of passing the address in as an input is not needed either. What the publish route still has unproven is the upload itself, which has never run, and that stays listed as such.Still unknown, and it is the interesting part
What the secrets detection reports. Run 375 built the report — 603 kB — and never uploaded it, because the upload is where the wrong key failed. No individual finding has been seen. That matters more than the rest of this change, because the premise of this repository is that no credential ever lands in it and nothing has ever checked that premise.
Wiki
helm-charts/CI-CD: the Sonar section rewritten — measured analyser table with the server-plugin cause and the consequence named, key and the missingprojectNameexplained, the "three things the first run answers" list turned into the three answers. Plus the publish-route section, which listed a repository variable reaching a cross-repository workflow as unproven: two of its three items are now proven by run 375 (the variable and the cross-repositoryuses:resolving), and only the upload remains.workflow-util/pipelines/Gemessenes-Verhalten: three new sections, one per measurement, each naming run 375 — and a note in the lead that confirmations belong on the page too, because an unwritten harmless quirk costs the same second measurement as a dangerous one.workflow-util/pipelines/sonar-analysis: the closing "not measured" list trimmed from four items to one. The one kept open is what an analysis reports, with the reason it survived a run that did scan. Added there: that the instance's actual analyser set is a thing every caller has to measure for itself, which is the item that should have been on the list from the start.What remains after the merge
One
workflow_dispatchofsonar.yml— the trigger is on the hull for this, so no dummy commit onmainis needed. That is the maintainer's action (the bot cannot dispatch workflows), not open work in this repository. If it fails again with the same message, the key is no longer the suspect: the token then lacks "Execute Analysis" on the project in SonarQube.Scope
sonar-project.propertiesandREADME.md. No chart directory is touched, so nothing publishes on merge.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