jklein
f284d209f7
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Skipped
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Skipped
Validate Helm Charts / Install-test (pull_request) Skipped
Validate Helm Charts / Resource quantities (pull_request) Successful in 9s
SonarQube Analysis / SonarQube Analysis (push) Successful in 42s
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
51 lines
2.6 KiB
Properties
51 lines
2.6 KiB
Properties
# Project-specific half of the SonarQube analysis. The workflow is the shared
|
|
# block in workflow-util/pipelines and is identical for every repository that
|
|
# uses it; everything that is about THIS repository lives here.
|
|
#
|
|
# The key is the one the project already has on the server, given by the
|
|
# maintainer. It is not derivable and must not be guessed: the project is
|
|
# created in SonarQube first, and the key is then read off it.
|
|
#
|
|
# The first attempt here was a guess, "jlab-cluster_helm-charts", reasoned from
|
|
# the instance serving two owners. It failed with
|
|
#
|
|
# 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.
|
|
#
|
|
# which is the message for BOTH a wrong key and a token without "Execute
|
|
# Analysis" on the project - the server does not distinguish them, so a wrong
|
|
# key here looks exactly like a permission problem over there. Once the key is
|
|
# known to be right, that message means the token.
|
|
sonar.projectKey=JLab-Helm-Charts
|
|
|
|
# NO sonar.projectName, deliberately.
|
|
#
|
|
# The project exists on the server, so the display name belongs to the server:
|
|
# whoever renames it there expects the rename to hold. A name sent with the
|
|
# analysis would overwrite it on every single run, silently, and the person who
|
|
# renamed it would only see it snap back. A value that rewrites someone else's
|
|
# setting without saying so is not a value this repository carries. If the name
|
|
# is wrong, it gets fixed in SonarQube, not here.
|
|
|
|
# The whole tree, which is also the scanner's default - stated rather than
|
|
# implied, because the absence of exclusions below is a decision and an empty
|
|
# file would not show that.
|
|
sonar.sources=.
|
|
|
|
# NO EXCLUSIONS, deliberately, for the first round.
|
|
#
|
|
# The interesting case is the Helm templates: because of {{ }} they are not
|
|
# valid YAML, and what the Helm and YAML analysers do with them is something we
|
|
# can only find out by letting them run over them once. Excluding them up front
|
|
# would throw away the only chance to learn it, and it would exclude the 26
|
|
# chart template directories that are the bulk of this repository.
|
|
#
|
|
# The same goes for the secret detection, which is the most valuable analyser
|
|
# here: the premise of this repository is that no credential ever lands in it -
|
|
# every secret is a 1Password OnePasswordItem reference - and until now nothing
|
|
# checked that premise.
|
|
#
|
|
# If the first run produces noise that is genuinely not worth reading, the
|
|
# exclusions belong here, with the finding they answer named in a comment. Not
|
|
# before: an exclusion written on a guess hides whatever else matched it.
|