Kai Ole Hartwig
pinup · Dokumentation

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>, %s für den Projektpfad, schemaVersion 1

Die Felder

Oben

FeldBedeutung
pinupVersion, generatedAtwelches pinup wann geplant hat
repo.pathdas Projekt
limitsprHourlyLimit, prConcurrentLimit wie aufgelöst; der Runner setzt sie durch
dashboardob das Dashboard-Issue geführt wird, und sein Titel
branchingprefix und während einer Umbenennung prefixOld; der Runner zählt und räumt unter beiden
deps, updates, branches, warnings, statssiehe unten
unmanagednur 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:

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.json

Weiter

Zurück zu pinup

Die Übersicht: Problem, Fit-Check, Quickstart, alle Kapitel.

pinup →
Zurück zu pinup

Effective-Label

Das zweite Label auf jedem Update: der Helm-Chart-Analyzer, die Sicherheitsregel, matchEffective und trustEffective.

Lesen →
Effective-Label