Der target-Cache (aus dem vorherigen Caching-Fix) haelt zwischen
Laeufen auch target/debian, target/generate-rpm und target/arch am
Leben, obwohl diese nie geleert wurden. Bei einem Cache-Treffer
wurden dadurch alte .deb/.rpm/.pkg.tar.zst-Dateien aus frueheren
Builds wiederhergestellt und beim Registry-Publish erneut mit
hochgeladen - Gitea lehnte die bereits existierende Datei mit 409
ab und riss den kompletten Schritt ab, bevor die eigentlich neue
Datei drankam (beobachtet beim RPM-Upload trotz korrekt berechneter
neuer Build-Nummer).
Die drei Paketierungs-Ausgabeordner werden jetzt direkt nach dem
Cache-Restore geleert, der eigentliche Kompilierungs-Cache
(target/<triple>/release/...) bleibt davon unberuehrt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
Die bisherige Abfrage GET /api/v1/packages/{owner}?limit=50 listete
alle Pakete des Owners ungefiltert (inkl. Docker-Image-Tags aus
main.yaml/testing.yaml), ohne Pagination. Dadurch konnte die
tatsaechlich relevante Paket-Version verdraengt werden, das Skript
hielt eine bereits genutzte Build-Nummer faelschlich fuer frei, und
der anschliessende Registry-Upload schlug mit 409 (Datei existiert
bereits) fehl - beobachtet beim RPM-Upload.
Fragt jetzt stattdessen gezielt pro Paket-Typ (debian/rpm/arch) die
Latest-Version ab (GET .../{type}/{name}/-/latest, ein Request ohne
Pagination). Alle drei Ergebnisse fliessen weiterhin in dasselbe Set
ein, sodass die naechste Build-Nummer weiterhin als globales Maximum
ueber alle Typen hinweg berechnet wird - deb/rpm/arch bleiben also
mit einer gemeinsamen Nummer synchron, auch wenn ein frueherer Lauf
nur bei einem der Typen erfolgreich hochgeladen hat.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
types: opened/synchronize/reopened explizit eingetragen, damit der
Workflow sicher auch bei neuen Commits auf einem offenen PR
(synchronize) erneut laeuft, statt sich auf ein nicht dokumentiertes
Gitea-Actions-Default zu verlassen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
Neuer Workflow, der bei jedem PR mit Ziel-Branch testing
cargo test ausfuehrt. Nutzt denselben Cargo-Cache-Key wie
main.yaml/testing.yaml, damit sich der Cache zwischen den
Workflows teilen laesst.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
- cargo-binstall/cargo-deb/cargo-generate-rpm auf feste Versionen
gepinnt (vorher "latest", nicht reproduzierbar) und ~/.cargo/bin
versionsbasiert gecacht
- rustup target add fuer aarch64/i686 in eigenen Schritt ausgelagert
und ~/.rustup/.../lib/rustlib/<target> gecacht, Cache-Key basiert
auf der aufgeloesten rustc-Version (nicht auf dem gleitenden
"stable"-Label), damit bei einem Rust-Update kein veralteter
Cache mit neuerem Compiler gemischt wird
- x86_64-unknown-linux-gnu aus rustup target add entfernt (Host-
Target, war bereits Teil der stable-Toolchain, No-Op)
- drei neue customManagers-Eintraege in renovate.json fuer
cargo-binstall (github-releases) sowie cargo-deb/cargo-generate-rpm
(crates.io), damit Renovate die gepinnten Versionen aktuell haelt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
Automatisiertes Werkzeug zum Extrahieren, Herunterladen und Spiegeln vorkompilierter Linux-Pakete aus GitHub-Releases in eine selbstgehostete Gitea- / Forgejo-Paket-Registry.
Automatisiertes Werkzeug zum Extrahieren, Herunterladen und Spiegeln vorkompilierter Linux-Pakete aus GitHub-Releases in eine selbstgehostete Gitea- / Forgejo-Paket-Registry.
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.