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
- main.yaml/testing.yaml: Cargo-Registry & target/ ueber Cargo.lock-Hash
gecacht (groesster Zeitfresser bei 3 Cross-Compile-Targets)
- security-scan.yaml: Trivy- und OSV-Scanner-Binary versionsbasiert
gecacht, zusaetzlich Trivy-Vulnerability-DB tagesbasiert gecacht
(sonst voller OCI-Download bei jedem Lauf)
- trufflehog-scan.yaml: TruffleHog-Binary versionsbasiert gecacht
Installation aller drei Scanner-Binaries von sudo-basiertem
/usr/local/bin auf $HOME/.local/bin umgestellt, da actions/cache
sonst ohne sudo nicht zuverlaessig in root-Verzeichnisse restoren
kann. TRIVY_VERSION/OSV_SCANNER_VERSION/TRUFFLEHOG_VERSION dafuer auf
Job-Ebene verschoben (Cache-Steps brauchen sie fuer den Cache-Key);
die Renovate-customManagers-Regexe matchen weiterhin, da sie auf dem
rohen Dateitext arbeiten statt auf der YAML-Struktur.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
baseBranches auf dev eingeschraenkt, passend zum bestehenden
dev -> testing -> main Promotion-Flow. Renovate liest Dependency-
Dateien jetzt direkt von dev und oeffnet PRs nur dort; main/testing
werden nicht separat gescannt. Die renovate.json selbst muss laut
Renovate-Doku trotzdem ueber den Gitea-Default-Branch (main)
gefunden werden koennen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
- Actions-Gruppe jetzt dateibasiert (matchFileNames statt
matchManagers), da die Custom-Regex-Manager für Trivy/OSV-Scanner/
TruffleHog als Manager-Typ "regex" laufen und von
matchManagers: ["github-actions"] nicht erfasst wurden
- Neue eigene Gruppe für alle Cargo-Dependencies
- separateMajorMinor/separateMinorPatch in allen drei Gruppen
deaktiviert, sonst reisst Renovate Major-Updates trotz groupName
standardmaessig in einen eigenen PR
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
- Trivy 0.70.0 -> 0.74.0, Renovate-Container 43.279.0 -> 44.79.2
(OSV-Scanner und TruffleHog waren bereits aktuell)
- OSV-Scanner- und TruffleHog-Versionen in Env-Vars ausgelagert
(TruffleHog nutzte die Version zuvor zweimal im String, das
verhinderte einen sauberen Regex-Match)
- Neuer customManagers-Regex-Block in renovate.json, da die drei
Scanner-Versionen als curl-Strings in run-Blöcken stecken und vom
github-actions-Manager (nur uses:/container:/services:) nicht
erfasst werden
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
setup-trivy's Install-Step macht immer einen git clone von
aquasecurity/trivy gegen github.com, unabhängig vom Cache-Status. Das
scheitert im Gitea act_runner mit "could not read Username for
'https://github.com'", da der Git-Smart-HTTP-Handshake blockiert wird.
Plain curl-Downloads von GitHub-Release-Assets funktionieren dagegen
(siehe OSV-Scanner-Step), daher wird Trivy jetzt genauso installiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
Der vorherige Fix (token-setup-trivy: "") schlug fehl: der act_runner
wertet einen leeren String-Input offenbar als "nicht angegeben", statt
ihn als expliziten leeren Wert an actions/checkout durchzureichen -
dessen eigener required-Input "token" fehlt dadurch komplett und der
Schritt bricht ab ("Input required and not supplied: token").
Damit lässt sich der git-basierte Installationsweg von setup-trivy
(Checkout von github.com/aquasecurity/trivy) nicht zuverlässig unter
Gitea nutzen. Trivy wird jetzt wie schon TruffleHog per curl direkt
von den GitHub-Releases installiert, trivy-action überspringt die
eigene Installation via skip-setup-trivy und nutzt nur noch die
Scan-Funktionalität.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FKMjR9pBxshZYZdhKyT5Ky
Bei Cache-Restore-Fehlschlag fällt setup-trivy auf einen Git-Checkout
von aquasecurity/trivy zurück, um das Install-Skript zu holen. Dabei
wird github.token als Auth-Token an github.com übergeben - unter Gitea
ist das aber der lokale Gitea-Runner-Token, der von GitHub abgelehnt
wird (401, danach Abbruch wegen deaktivierter Prompts). token-setup-trivy
leer lassen, damit der Fallback-Checkout anonym gegen das öffentliche
GitHub-Repo läuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FKMjR9pBxshZYZdhKyT5Ky
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.