From f8c4ea123ef78f212adbaf91c5d401694c8c3f04 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Fri, 2 Oct 2026 00:21:18 +0000 Subject: [PATCH] Lauf 399 festhalten, und die Lehre aus der Analysator-Tabelle Die Analyse laeuft durch (44 s, ANALYSIS SUCCESSFUL). Was sie gefunden hat, ist von hier aus nicht lesbar: die API antwortet anonym mit 401, was die richtige Einstellung ist - die Zahlen kommen also von einem Konto auf dem Server, nicht aus einem Protokoll. Dazu der Eintrag zur Tabelle, die ich aus einer Produktdokumentation gebaut und als Zusage ueber diese Instanz verwendet habe. Shell und GitHub Actions laufen hier nicht, weil Analysatoren server-seitige Plugins sind. --- CI-CD.md | 6 ++++-- Lessons-Learned.md | 13 +++++++++++++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/CI-CD.md b/CI-CD.md index ef84339..14d5d50 100644 --- a/CI-CD.md +++ b/CI-CD.md @@ -231,7 +231,9 @@ Whether the instance is upgraded or has those plugins added is a decision for wh **The secrets row is the reason to bother, and it does run.** The premise of this repository is that a credential never lands in it — every secret is a 1Password `OnePasswordItem` reference, materialised by the operator in the cluster — and until now *nothing checked that premise*. The two surviving rows above it are a second opinion on something `helm lint --strict`, the render test or Trivy already touch; this one covers an assumption carried for two years on discipline alone. -**What it reports is still unknown.** Run 375 built the report — 603 kB — and never uploaded it, because the upload is exactly where the wrong project key failed. The log names no individual findings. The first successful run is what shows them, and that is the most interesting part of this whole addition. +**The analysis itself works.** Run 399, the push that merged the corrected project key, finished **successful in 44 seconds** and reported `ANALYSIS SUCCESSFUL, you can find the results at: https://sonar.jk-dev.de/dashboard?id=JLab-Helm-Charts`. Sensors that did work: IaC Kubernetes, `TextAndSecretsSensor`, the JavaScript/TypeScript/CSS sensor (which finds nothing here) and the IaC project sensor. Shell and GitHub Actions remain absent, as in run 375. + +**What it found is not readable from the pipeline.** The findings live on the server, and that server does not answer anonymously: `api/measures/component` replies **401** while the dashboard page itself returns 200. That is the right setting — an instance that hands out analysis results to anyone would be a finding in its own right — but it means the numbers have to come from whoever has an account there, not from a log. Whether the Helm templates produce noise, and whether the secrets detection finds anything in a repository whose whole premise is that it holds no credential, can only be read off that dashboard. ### No exclusions, for the first round @@ -276,7 +278,7 @@ Run 375, a push to `main`. It was red at the upload, but everything before the u All three are recorded on [`Gemessenes-Verhalten`](https://git.jk-dev.de/workflow-util/pipelines/wiki/Gemessenes-Verhalten) in `workflow-util/pipelines`, which is where measurements about the forge itself belong; they are repeated here only because the run happened on this side. -**Still open, and it is the interesting one: what the analysis actually reports.** The report was built (603 kB) and never uploaded, so no finding — from the Helm templates or from the secrets detection — has been seen yet. That is also what decides whether exclusions are needed, and they would go into `sonar-project.properties`. +**Answered since, by run 399:** the analysis completes (44 s, `ANALYSIS SUCCESSFUL`). What it *found* is still unseen from here, and for a structural reason rather than a missing run — the server refuses anonymous API reads (`401` on `api/measures/component`), so the findings are only visible to an account on it. Whether exclusions are warranted therefore depends on a look at the dashboard, not on another run; if they are, they go into `sonar-project.properties`. `workflow_dispatch` is on the hull for exactly these retries, and it is what proves the corrected key: one dispatch, no dummy commit on `main`. Only the maintainer can trigger it — the bot account cannot dispatch workflows. diff --git a/Lessons-Learned.md b/Lessons-Learned.md index 1f59f54..b36d964 100644 --- a/Lessons-Learned.md +++ b/Lessons-Learned.md @@ -220,6 +220,18 @@ That comment still reads as a complete justification. Nothing about it looks bro **Now:** before a file leaves the repository, grep for its name across the whole tree, **comments included**, not only the `uses:` and `include` lines that a tool would find. All three cases here came out of that one grep, and none of them was in the diff the move itself produced. +## The capability list that described a product, not our server + +The plan for the Sonar analysis carried a table: 5 shell scripts under `ci/` → Shell analyser, 30 workflow files → GitHub Actions analyser, charts → Kubernetes/Helm, schemas → JSON, everything → Secrets. It was taken from SonarQube's "supported languages" page, and it was used to argue that the addition was worth having — *the files with the actual logic get analysed*. + +The first run loaded **two quality profiles, `json` and `yaml`**. The sensors that did work were IaC Kubernetes and the secrets detection. **Shell and GitHub Actions never ran**, because analysers are **server-side plugins** and this instance does not have them. + +The error was not the table. It was the move from "the product supports X" to "our pipeline will analyse X" — a documentation page describes the newest release of someone else's software, and says nothing about the installation we actually call. The gap was invisible because both halves were true: the product does support Shell, and our scanner did run. + +**Now:** the table in README and on this page carries a third column, *"Runs?"*, filled in from a measured run and headed as measured rather than quoted. The two "no" rows are the valuable ones — they say plainly that the five `ci/` scripts and the thirty workflow files are not analysed at all, so nobody mistakes the addition for a check it is not. + +Generally: **a capability list is about the product; only a run is about the installation.** The same shape as a stale context block — both read as authoritative, and neither is the thing you are actually talking to. + ## The recurring shape - **Green is a claim about the assertions that ran, not about the system.** @@ -230,5 +242,6 @@ That comment still reads as a complete justification. Nothing about it looks bro - **Write down what was measured, and say when something was not.** Half of this page exists because someone recorded a number instead of an impression. - **A document handed to you as context is a copy, not the source.** Correcting the file does not correct the copies already delivered, and a stale copy looks exactly as authoritative as a current one — only the file itself, and its diff against `origin/main`, settle what a rule says. - **Put the warning where the next change will be made.** A risk that only materializes at the next upgrade belongs at the line that upgrade will touch — a note in the pull request that argued the decision is read once, by people who already know. +- **A capability list is about the product; only a run is about the installation.** "Supported" on a documentation page and "enabled on the server we call" are different claims, and the first one reads like a promise. - **A reference to something that moved is false, not stale.** It still answers the question, which is why nobody re-asks it — so a file leaving the repository is a grep across the whole tree, comments included, not only the lines a tool can resolve. - **An answer that arrived by accident is worth making repeatable.** The all-charts install-test exists because one unplanned run produced a result nobody could have asked for; the fix is a way to ask the question on purpose, not a note to remember the accident.