Die komplette Ausgabezeile wird nun abhängig vom Schweregrad eingefärbt
(Error rot, Warn gelb, Info grün, Debug cyan), aber nur wenn stdout/stderr
ein echtes Terminal ist und weder NO_COLOR noch TERM=dumb gesetzt sind.
Die Logdatei bleibt unverändert klartextbasiert ohne ANSI-Codes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
'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>
'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>
Prüft vor Build & Tests per Gitea Package-API, ob die aktuelle Crate-Version
schon in der Registry existiert, und bricht den Release/Publish-Job dann
gar nicht erst an, statt an einem Registry-Fehler zu scheitern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K2DxAVavuu4vMb2MC2G15g
Fügt einen vorgeschalteten detect-changes-Job ein, der mittels
dorny/paths-filter@v4 prüft, ob sich Programmcode (src/, Cargo.toml,
Cargo.lock, scripts/, .cargo/ bzw. die jeweilige Workflow-Datei selbst)
geändert hat. Der Build-/Publish-/Release-Job wird nur noch ausgeführt,
wenn das der Fall ist; bei reinen Config- oder Workflow-Änderungen
schließt der Workflow erfolgreich ohne Build/Release ab.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TcFzG54jW33nvp1TawCZJV
-`Warn` (2) — Warnungen (Ausgabe auf `stdout` mit `[?]`-Präfix)
-`Info` (3) — Betriebsinformationen (Ausgabe auf `stdout` mit `[i]`-Präfix)
-`Debug` (4) — Diagnoseausgaben (Ausgabe auf `stdout` mit `[d]`-Präfix)
- **Farbige Terminalausgabe**: Jede Zeile wird je nach Schweregrad eingefärbt (`Error` rot, `Warn` gelb, `Info` grün, `Debug` cyan). Farben werden nur ausgegeben, wenn `stdout`/`stderr` ein echtes Terminal ist (keine Umleitung in Datei/Pipe), `NO_COLOR` nicht gesetzt ist und `TERM` nicht `dumb` ist. Die Logdatei enthält stets reinen Text ohne ANSI-Codes.
- **Threadsicherheit**: Dateischreibzugriffe und Konfiguration sind thread-sicher serialisiert.
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.