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
deps, updates, branches, warnings, statssiehe unten

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.

updates

Ein Eintrag pro Bewegung: dep, newValue (die geschriebenen Bytes), newVersion, newDigest, updateType (major, minor, patch, digest, pin, pinDigest, rollback, lockFileMaintenance, majorAvailable), declared und effective, analyzer und evidence, releaseTime mit timeSource, securityFix – und:

branches

Ein Eintrag pro Branch: name (Renovate-kompatibel), title, 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

# 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