Kai Ole Hartwig
pinup · Dokumentation

Effective-Label

Jedes Update trägt zwei Labels. Der Fall dahinter: ein Chart-Anbieter, der bei jedem Release die Major-Version hochzählt. Nach dem deklarierten Label ist jedes davon ein Major und wartet auf Freigabe. Die Anwendung darin und die Values, die du setzt, sind oft dieselben wie vorher.

  • Declared kommt aus den Versionsstrings, immer: major, minor, patch, digest, pin, pinDigest, rollback. Das liest matchUpdateTypes.
  • Effective kommt von einem Analyzer, der nachgesehen hat, was sich wirklich geändert hat: unknown, solange keine Regel gefragt hat, sonst patch, minor, major oder breaking-values.

Die Sicherheitsregel

Eine Automerge-Entscheidung nimmt das strengere der beiden Labels. Ein Analyzer darf eine Entscheidung nur lockern, wo eine Regel sagt, dass seinem Wort zu trauen ist: trustEffective: true. Ohne das bleibt ein Automerge aus, den eine matchEffective-Regel eingeschaltet hat; der Request wird trotzdem geöffnet, und seine Evidenz-Tabelle sagt warum. Ein Analyzer kann ein Update nie strenger machen, als die Regeln es schon gemacht haben, und er lässt nie eine Regel feuern, indem er fehlt: unknown ist kein Wert, den matchEffective matcht.

Danach fragen

 

"packageRules": [
  { "matchDatasources": ["docker"], "matchPackageNames": ["registry-1.docker.io/bitnamicharts/**"],
    "versioning": "semver", "analyze": true },
  { "matchDatasources": ["docker"], "matchUpdateTypes": ["major"],
    "matchEffective": ["patch", "minor"], "trustEffective": true,
    "automerge": true, "dependencyDashboardApproval": false }
]

 

Die erste Regel markiert die Abhängigkeiten (analyze ist standardmäßig aus, weil der Analyzer beide Versionen holt). Die zweite liest das Label: ein deklariertes Major, dessen effektives Label patch oder minor ist, öffnet ohne Freigabe und merged von allein. Ein breaking-values matcht keines davon; das Major bleibt, was die anderen Regeln daraus machen.

Der Helm-Chart-Analyzer

Gilt für helm-Abhängigkeiten (die index.yaml eines Chart-Repositories nennt das Archiv pro Version) und für docker-Abhängigkeiten, deren Tag ein Chart ist – so tragen OCI-Registries Charts: die Config des Manifests ist application/vnd.cncf.helm.config.v1+json, der Layer das Archiv. Ein Docker-Tag, das ein Image ist, geht den Analyzer nichts an und bleibt unknown.

Er liest Chart.yaml und values.yaml beider Versionen:

VerglichenUrteil
appVersiondie eigene Bewegung der Anwendung: major, minor, patch, unchanged; not stated oder not comparable lassen das Label unbekannt
values.yaml-Keys, zu Pfaden geflachtein Key, den das neue Chart nicht mehr hat, ist ein Wert, den du gesetzt haben könntest und der jetzt nichts mehr tut: breaking-values, das strengste Label, egal was appVersion tat; neue Keys werden gezählt
kubeVersionein geänderter Constraint, als Evidenz
dependenciesdie Bewegung jedes Subcharts, als Evidenz

Gemessen gegen Docker Hubs bitnamicharts/redis, 20.13.4 → 28.1.0: appVersion 7.4.3 → 8.10.1 (major), zwei Values-Keys entfernt (sentinel.externalAccess.service.loadBalancerIP …) → breaking-values, Automerge aus. Dasselbe Chart von 20.13.4 auf ein 21.0.0, bei dem Anwendung und Values stehen, liest patch.

Was der Merge Request zeigt

Unter der Update-Tabelle, pro analysiertem Update:

 

**registry-1.docker.io/bitnamicharts/redis**: declared major, effective breaking-values (helm-chart)

| Compared     | From    | To       | Finding                                   |
|--------------|---------|----------|-------------------------------------------|
| appVersion   | `7.4.3` | `8.10.1` | major                                     |
| values       | —       | —        | 2 keys removed, 19 added: sentinel.…      |
| dependencies | `2.x.x` | `2.41.0` | common                                    |

 

Und, wo eine Regel Automerge ohne trustEffective eingeschaltet hat, eine Zeile mehr: welche Regel es war und was es erlauben würde.

Noch nicht gebaut

helm template mit deinen eigenen Values als Plugin, mit Diff der gerenderten Manifeste; ein docker-image-Analyzer über OCI-Labels und Attestations. Die Schnittstelle ist classify.Analyzer; ein Analyzer ist ein Paket unter analyzer/ und eine Zeile in wire.

Weiter

Zurück zu pinup

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

pinup →
Zurück zu pinup

Tasks und Plugins

Lock-Refreshes und Post-Upgrade-Kommandos: was läuft, in welchem Scope, mit welcher Umgebung.

Lesen →
Tasks und Plugins