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 und mit overrideDatasource, overridePackageName und extractVersion bestimmen, wo nachgeschlagen wird), 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, overrideDatasource, 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
• overridePackageName – ein fester Name; Renovates Templates werden nicht ausgewertet
• 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 --plan plan.json --repo .   # dazu gepinnte Versionen, die nichts aktualisiert
pinup advise --config renovate.json --fix --out fixed.json
pinup advise --init --out .pinup.jsonc                          # ein erster Vorschlag für ein Repository ohne Konfiguration

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. Mit --repo kommt der Checkout dazu. Eine Version, die bewusst steht, markiert pinup: coverage-ignore auf ihrer Zeile oder der darüber.

--init ist für ein Repository ohne Konfiguration. Es liest den Checkout offline, ohne Token und ohne Lookup. Vorgeschlagen wird die kleinste passende .pinup.jsonc: config:recommended, drei Tage Mindestalter und Advisories, nur die Manager, die etwas gefunden haben, und für jede gepinnte Version ohne Manager die Annotation darüber. Bevor etwas ausgegeben wird, läuft der Vorschlag selbst durch advise. Findet advise etwas, scheitert der Befehl.

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