Der Plan
Jeder Lauf erzeugt einen maschinenlesbaren Plan, bevor er etwas schreibt: whatif hört dort auf, run macht weiter. Der Plan ist das Rückgrat, kein Debug-Flag. Der Vergleichsjob, das Dashboard, der Merge-Request-Text und der Estate-Bericht lesen ihn.
- Ein Plan erklärt, warum nichts passiert. Jedes gehaltene Update trägt seinen Grund, wann der Halt endet und welche Regel ihn gesetzt hat.
- Nichts hinter dem Plan erfindet eine Änderung. Branches tragen Byte-Range-Edits und Tasks; Apply verbraucht die, nie eine Abhängigkeit.
- Format: JSON,
--report <pfad>,%sfür den Projektpfad,schemaVersion1
Die Felder
Oben
| Feld | Bedeutung |
|---|---|
pinupVersion, generatedAt | welches pinup wann geplant hat |
repo.path | das Projekt |
limits | prHourlyLimit, prConcurrentLimit wie aufgelöst; der Runner setzt sie durch |
dashboard | ob das Dashboard-Issue geführt wird, und sein Titel |
branching | prefix und während einer Umbenennung prefixOld; der Runner zählt und räumt unter beiden |
deps, updates, branches, warnings, stats | siehe unten |
unmanaged | nur mit --coverage: gepinnte Versionen, die nichts aktualisiert, als {file, line, value} |
deps
Ein Eintrag pro Abhängigkeit pro Datei: manager, file, depName, packageName, currentValue, currentDigest, lockedVersion, datasource, versioning, registryUrls, die Werte aus dem Vor-Lookup-Regelpass (rangeStrategy, minimumReleaseAge, pinDigests), der locus (Byte-Offsets von Wert und Digest) und bei Custom Managern der Index und die captures. Eine nicht nachgeschlagene Abhängigkeit sagt warum in skipReason; eine von einer Regel deaktivierte nennt die Regel in disabled.
allowedVersions ist die Grenze, die eine Regel gesetzt hat, allowedVersionsBy die Regel. Schließt die Grenze jede neuere Version aus, steht in skipReason nicht „up to date“, sondern etwa held by allowedVersions "/^8\.2\./" (packageRules[12]): 3 newer releases excluded, the newest 8.5.2. Bekommt die Abhängigkeit ein erlaubtes Update und hält die Regel trotzdem Neueres zurück, steht derselbe Satz in heldBack. Das Dashboard zeigt beides an der Abhängigkeit.
updates
Ein Eintrag pro Bewegung: dep, newValue (die geschriebenen Bytes), newVersion, newDigest, updateType (major, minor, patch, digest, pin, pinDigest, rollback, lockFileMaintenance, majorAvailable), stream bei einem majorAvailable eines Serien-Pins (das Geschwisterpaket der höheren Serie), declared und effective, analyzer und evidence, releaseTime mit timeSource, securityFix. Dazu:
blocks: jeder Grund, aus dem das Update gehalten wird.reason,origin(config,packageRules[N]oder eine Datei im Repository wiefile:.npmrcmitpointer),until,note. Gründe:minimumReleaseAge,schedule,dependencyDashboardApproval,disabled,allowedVersions,internalChecksFilter,hourlyLimit,concurrentLimit,rollingMajor,pluginRequired,taskRefused,nothingToRefresh,publishFailed,closedByHand(ein Mensch hat den Merge Request mit genau diesen Änderungen geschlossen; ein geändertes Update öffnet wieder),narrowedRun(ein auf ein Paket eingeschränkter Lauf, etwa die Fast Lane, hält einen Gruppen-Branch, auf dem schon ein offener Merge Request liegt: Er sieht nur einen Teil der Gruppe und würde die übrigen Updates verlieren. Ein Gruppen-Branch ohne offenen Request wird geschrieben.).disabledundallowedVersionssind Urteile der Konfiguration, kein Warten: Ein voller Lauf schließt einen Merge Request, dessen Branch dafür gehalten wird.suppressedBy: der erste Grund, für Leser, die ein Wort brauchen.notes,compareUrl: die Release-Notes zwischen den Versionen und die Compare-Seite der Forge.
branches
Ein Eintrag pro Branch: name (Renovate-kompatibel), plannedName während einer Umbenennung, title, commitBody, groupName, updateKeys, edits (Datei, Byte-Range, alte und neue Bytes, Manager), tasks (Lock-Refreshes und Post-Upgrade-Kommandos mit ihrem Scope), automerge, labels, schedule, existing (der offene Merge Request) und suppressedBy mit heldWith, wo der Branch als Ganzes gehalten wird.
warnings
stage (config, extract, lookup, analyze, apply, publish, cache), file, msg. Eine unerreichbare Datenquelle, ein Preset, das zu nichts auflöst, ein Task, dessen Ausgabe seinen Scope verlassen hat, ein zu junger Cache: Warnungen, nie ein gescheiterter Lauf für den Rest des Repositories.
Einen Plan lesen
# jedes gehaltene Update mit seinem Grund
jq -r '.updates[] | select(.blocks) | "\(.dep.depName) \(.dep.currentValue) -> \(.newValue): \(.blocks[0].reason) (\(.blocks[0].origin.source))"' plan.json
# was allowedVersions zurückhält, mit oder ohne erlaubtes Update
jq -r '.deps[] | (.heldBack // .skipReason // "") as $r | select($r | startswith("held by")) | "\(.depName) \(.currentValue): \($r)"' plan.json
# die Branches, die jetzt geschrieben würden
jq -r '.branches[] | select(.suppressedBy == null) | .name' plan.jsonWeiter
Effective-Label
Das zweite Label auf jedem Update: der Helm-Chart-Analyzer, die Sicherheitsregel, matchEffective und trustEffective.