Konfiguration

Merge-Semantik

Die Regeln sind Renovates, gemessen dagegen:

• Objekte mergen tief, Arrays ersetzen, null löscht einen Schlüssel.
• packageRules hängen sich über alle Schichten aneinander und gelten in Array-Reihenfolge. Für eine Abhängigkeit gilt jede passende Regel, spätere gewinnen pro Schlüssel.
• Regeln laufen zweimal, wie in Renovate: einmal pro Abhängigkeit vor dem Lookup (Regel kann deaktivieren, Versioning und Registries ändern), einmal pro Update, wenn matchUpdateTypes und matchEffective bekannt sind.
• Ein Matcher auf ein unbekanntes Feld passt nicht. Eine matchUpdateTypes-Regel schweigt vor dem Lookup, eine matchEffective-Regel, bevor ein Analyzer lief.

Jeder aufgelöste Wert behält seine ganze Herkunftskette. pinup print-config --config … --explain packageRules[25].automerge zeigt jede Quelle, die einen Pfad gesetzt hat, Gewinner zuletzt. Ein gehaltenes Update im Plan nennt die Regel genauso.

Die Schlüssel

pinup migrate --config … stuft jeden Schlüssel ein. Unterstützt heißt: der Schlüssel tut, was er in Renovate tut, gemessen. Teilweise nennt die Differenz. Nicht unterstützt heißt: nichts liest ihn, und der Lauf sagt es.

Unterstützt

$schema, addLabels, additionalBranchPrefix, allowedCommands, allowedVersions, automerge, branchPrefix, branchTopic, commitMessageAction, commitMessageExtra, commitMessageLowerCase, commitMessagePrefix, commitMessageSuffix, commitMessageTopic, customDatasources, customManagers, dependencyDashboard, dependencyDashboardApproval, dependencyDashboardTitle, description, enabled, enabledManagers, extends, extractVersion, fetchChangeLogs, groupName, groupSlug, ignoreDeps, ignorePaths, ignoreUnstable, internalChecksFilter, labels, lockFileMaintenance, matchCurrentValue, matchDatasources, matchDepNames, matchDepTypes, matchFileNames, matchManagers, matchPackageNames, matchUpdateTypes, minimumReleaseAge, minimumReleaseAgeBehaviour, osvVulnerabilityAlerts, packageRules, pinDigests, platformAutomerge, postUpgradeTasks, prBodyDefinitions, prBodyNotes, prConcurrentLimit, prHourlyLimit, rangeStrategy, registryUrls, schedule, semanticCommitScope, semanticCommitType, semanticCommits, separateMajorMinor, timezone, versioning, vulnerabilityAlerts – und pinups eigene analyze, matchEffective, trustEffective.

Teilweise

• matchCurrentVersion – als Version gematcht, nicht als Range
• matchSourceUrls – die URL, wie die Datenquelle sie meldet
• matchJsonata – nur isLockfileUpdate und sourceUrl
• commitBody – gelesen, nicht templatisiert
• prCreation – nur immediate; der Not-Pending-Deadlock ist per Design weg
• rebaseWhen – ein Branch mit fremden Commits bleibt unberührt, sonst Rebase bei Konflikt
• separateMinorPatch, separateMultipleMajor, separateMultipleMinor – in die Template-Variablen gelesen; separateMajorMinor entscheidet
• postUpdateOptions – gomodTidy tut der gomod-Lock-Refresh ohnehin, der Rest wird nicht gelesen
• executionTimeout – entscheidet der Runner (PINUP_EXECUTION_TIMEOUT), nie ein Repository

Nicht unterstützt

• matchCategories – kein Kategorie-Modell; die Regel feuert nie, und migrate sagt es

Ein Schlüssel, der hier nicht steht, wird nicht gelesen; migrate listet ihn als nicht unterstützt.

pinups eigene Schlüssel

Custom Manager

customManagers mit customType: regex arbeiten wie in Renovate: RE2-Ausdrücke mit benannten Gruppen (depName, currentValue, currentDigest, datasource, versioning, registryUrl, packageName, extractVersion), die *Template-Schlüssel mit einer Handlebars-Teilmenge ({{{x}}}, {{#if}}/{{else}}, {{#if (equals a "b")}}), matchStringsStrategyany und recursive. Eine eingefangene Gruppe schlägt ihr Template. # renovate: und # pinup: werden beide gelesen.

Umgebung

Konfiguration prüfen: pinup advise

pinup advise löst eine Konfiguration so auf, wie ein Lauf es tut, und sagt, was sich ändern sollte. Jeder Befund trägt seinen Pointer, die Schicht, die den Wert geschrieben hat – Datei, Preset oder Default –, und, wo die Datei den Wert selbst setzt, einen Fix.

pinup advise --config renovate.json --runner 'local>gruppe/pinup-runner'
pinup advise --config renovate.json --plan plan.json      # dazu, was die Läufe gefunden haben
pinup advise --config renovate.json --fix --out fixed.json

Mit --plan kommen die Läufe dazu: Regeln, die keine Abhängigkeit erreicht hat, Manager ohne Funde, ein Repository, dessen Updates alle eine Einstellung hält.

--fix wendet die Fixes byte-genau auf JSON, JSONC und JSON5 an. Kommentare, Reihenfolge und Formatierung bleiben. Geschrieben wird erst nach einem Gate: die Datei wird vorher und nachher aufgelöst, und jede Zeile, die sich unterscheidet, muss unter einem Pointer liegen, den ein Fix angemeldet hat. Ein Fix ohne Anmeldung muss die Auflösung unverändert lassen. Ohne --out oder --write ist es ein Probelauf. --skip hält Checks zurück, die eine Entscheidung brauchen. Eine YAML-Datei wird berichtet, nicht umgeschrieben.

Alle Checks mit ID, Schwere und Fix stehen in docs/commands.md im Repository.