'before 6am on monday' erlaubte nur einmal pro Woche automatische
PR-Erstellung - jeder außerhalb dieses Fensters gefundene Update musste
im Dependency-Dashboard-Issue erst manuell abgehakt werden ("Awaiting
Schedule"), auch nach der letzten Automerge-Änderung. 'before 6am' (ohne
Wochentag) öffnet das Fenster jetzt täglich, PRs für sichere Updates
laufen dadurch spürbar zeitnaher und größtenteils ohne manuelles
Abhaken durch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Patch-/Minor-/Digest-Updates (Cargo, Gitea Actions, Docker-Images)
werden künftig automatisch gemergt, sobald alle CI-Checks erfolgreich
sind - Major-Updates bleiben weiterhin manuell zu prüfen, da sie eher
brechende Änderungen enthalten.
Voraussetzung dafür: unit-tests.yaml (der eigentliche 'cargo test'-Lauf)
löste bisher nur bei Pull Requests gegen 'testing' aus, nicht gegen
'dev' - Renovate-PRs zielen aber auf 'dev' und wurden damit nie durch
einen echten Build/Test abgesichert, nur durch die Security-/Secret-
Scans. Jetzt läuft er auch dort.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ein rohes 'actions/cache' auf target/ lieferte zwar einen technischen
Cache-Hit, Cargo kompilierte die Abhängigkeiten aber trotzdem neu: der
tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten
Dateien dieselbe Mtime, wodurch Cargos Fingerprinting nicht mehr
zuverlässig erkennen kann, was älter/neuer als was ist. Swatinem/rust-cache
behebt das gezielt (u. a. gezielte Mtime-Korrektur nach dem Restore).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"description":"Patch-/Minor-/Digest-Updates automatisch mergen, sobald alle CI-Checks (inkl. Unit-Tests) erfolgreich sind - Major-Updates sind unten explizit ausgenommen (siehe nächste Regel).",
"matchUpdateTypes":[
"patch",
"minor",
"digest",
"lockFileMaintenance"
],
"automerge":true,
"automergeType":"pr",
"platformAutomerge":true
},
{
"description":"Major-Updates immer manuell prüfen, da potenziell brechende Änderungen.",
"matchUpdateTypes":[
"major"
],
"automerge":false
}
],
"customManagers":[
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.