Beschleunigt Renovates Reaktion auf Dependency-Dashboard-Checkboxen
(die den in renovate.json gesetzten wöchentlichen Update-Schedule
ohnehin umgehen) von bis zu einer Woche auf bis zu einer Stunde.
Tatsächliche neue Update-PRs entstehen weiterhin nur innerhalb des
renovate.json-Schedules (Montag vor 6 Uhr).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E7r1oHC5ezNRnDuneTRCtN
- Renovate-Workflow: Host in RENOVATE_HOST_RULES statt hartkodiert
über die bereits genutzte server_url-Expression bezogen
- GITHUB_COM_TOKEN (aus neuem Secret GH_RENOVATE_TOKEN) ergänzt, damit
Renovate GitHub-gehostete Dependencies authentifiziert statt
rate-limitiert abfragt
- allowCustomCrateRegistries in renovate.json aktiviert, da sonst
Lookups für die eigenen Cargo-Pakete (config-ctdra, logger-ctdra)
aus der Gitea-Registry fehlschlagen
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E7r1oHC5ezNRnDuneTRCtN
Aus dem /code-review-Lauf: Beide Dokumente behaupteten, die
Security-Scans liefen nur bei Push auf main/testing/dev. Das stimmt
fuer security-scan.yaml, aber trufflehog-scan.yaml hat keinen
branches-Filter und laeuft tatsaechlich bei Push auf jeden Branch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
- Caching in main.yaml und testing.yaml auf die konkreten Packaging-Binaries (~/.cargo/bin/cargo-binstall, cargo-deb, cargo-generate-rpm) eingeschraenkt, statt das gesamte ~/.cargo/bin-Verzeichnis zu sichern (verhindert das Wiederherstellen veralteter Rust-Compiler-Proxys bei Toolchain-Updates).
- AGENTS.md an das praezisierte Caching-Verhalten angepasst.
- scripts/report-security-issue.py sichert den Zugriff auf Umgebungsvariablen (GITEA_URL, REPO, TOKEN) per os.environ.get ab und ueberspringt die Gitea-Issue-Synchronisation bei fehlendem oder leerem Token (verhindert Auth-Crashes bei unprivilegierten PR-Workflow-Laeufen).
Co-authored-by: Junie <junie@jetbrains.com>
Beide Dokumente hinkten dem tatsaechlichen Stand der .gitea/workflows/
und renovate.json hinterher. Ergaenzt:
- Neue Workflow-Dateien (unit-tests, security-scan, trufflehog-scan,
renovate) und renovate.json in den Projektstruktur-Uebersichten
- AGENTS.md: neuer Abschnitt 5 mit Branch-Flow, actions/cache-Details
inkl. der target/-Bereinigungs-Falle, der Build-Nummer-Logik ueber
die Gitea-Packages-API und der Renovate-Gruppierung/baseBranches
- README.md: zwei weitere CI-Badges sowie ein kurzer CI/CD & Contributing-
Abschnitt fuer Branch-Flow, PR-Tests, Security-Scans und Renovate
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kh9v73QApBwJj96w6A8R55
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
@@ -77,7 +82,7 @@ Bei Änderungen an Binärnamen, Abhängigkeiten oder Beschreibungen müssen die
-`pkgrel`, `arch`, `depends`, `optdepends`.
### 3.3 Skripte in `scripts/`
- **Generizität**: Die Skripte dürfen keine hardcodierten Anwendungsnamen, spezifischen Abhängigkeiten oder projektspezifischen URLs enthalten. Alle Werte müssen dynamisch aus `Cargo.toml` oder Umgebungsvariablen (`BUILD_NUMBER`, `GITEA_URL`, `REPO`, `TOKEN`) ermittelt werden.
- **Generizität**: Die Skripte dürfen keine hardcodierten Anwendungsnamen, spezifischen Abhängigkeiten oder projektspezifischen URLs enthalten. Alle Werte müssen dynamisch aus `Cargo.toml` oder Umgebungsvariablen (`BUILD_NUMBER`, `GITEA_URL`, `REPO`,`REPO_OWNER`,`TOKEN`) ermittelt werden.
- **Python-Kompatibilität**: Verwende Standard-Python 3 ohne externe PyPI-Abhängigkeiten (nur Standardbibliothek).
-`push` auf `main`: Baut Binaries für alle 3 Architekturen, baut`.deb`,`.rpm` und `.pkg.tar.zst`, lädt sie in die Gitea Package Registry hoch, erstellt ein Gitea Release `v<VERSION>` und baut/veröffentlicht das Docker-Container-Image mit den Tags `:latest`, `:<VERSION>`, `:v<VERSION>` und `:<VERSION>.<BUILD_NUMBER>`.
-`push` auf `testing`: Baut Binaries & Pakete für den `testing`-Kanal, erstellt ein Pre-Release `v<VERSION>-preview` und baut/veröffentlicht das Docker-Container-Image ausschließlich mit eindeutigen Testing-Tags (`:testing`, `:<VERSION>-preview`, `:<VERSION>-testing`, `:<VERSION>-preview.<BUILD_NUMBER>`, `:testing-<BUILD_NUMBER>`). Der Tag `:latest` ist strikt dem `main`-Workflow vorbehalten.
-**Secrets**:
-`PACKAGE_TOKEN` (bzw. Fallback-Token-Namen wie `RELEASE_TOKEN`, `GITEA_TOKEN`) wird für API-Zugriffe auf Gitea Packages, Container Registry und Releases verwendet.
### 5.1 Branch-Flow & Trigger
Promotion-Flow:`dev` →`testing` → `main`, ausschließlich per Merge (nie direkt gepusht).
-`pull_request` mit Ziel-Branch `testing` (`unit-tests.yaml`): führt `cargo test` aus (`types: opened, synchronize, reopened`).
-`push` auf `main` (`main.yaml`): Baut Binaries für alle 3 Architekturen, baut `.deb`, `.rpm` und `.pkg.tar.zst`, lädt sie in die Gitea Package Registry hoch, erstellt ein Gitea Release `v<VERSION>` und baut/veröffentlicht das Docker-Container-Image mit den Tags `:latest`, `:<VERSION>`, `:v<VERSION>` und `:<VERSION>.<BUILD_NUMBER>`.
-`push` auf `testing` (`testing.yaml`): Baut Binaries & Pakete für den `testing`-Kanal, erstellt ein Pre-Release `v<VERSION>-preview` und baut/veröffentlicht das Docker-Container-Image ausschließlich mit eindeutigen Testing-Tags (`:testing`, `:<VERSION>-preview`, `:<VERSION>-testing`, `:<VERSION>-preview.<BUILD_NUMBER>`, `:testing-<BUILD_NUMBER>`). Der Tag `:latest` ist strikt dem `main`-Workflow vorbehalten.
-`push`/`pull_request`/wöchentlich (`security-scan.yaml`, `trufflehog-scan.yaml`): Trivy (vuln/secret/misconfig) & OSV-Scanner laufen bei Push auf `main`/`testing`/`dev` sowie bei jedem PR; TruffleHog hat **keinen**`branches`-Filter und läuft bei Push auf **jeden** Branch (zusätzlich bei jedem PR). Funde werden per `scripts/report-security-issue.py` als Gitea-Issue gemeldet.
- stündlich, `workflow_dispatch` (`renovate.yaml`): Renovate (containerisiert via `ghcr.io/renovatebot/renovate`) prüft Dependency-Updates, siehe 5.5. Der stündliche CI-Lauf steuert nur, wie schnell Renovate reagiert (z.B. auf Dependency-Dashboard-Checkboxen); tatsächliche neue Update-PRs entstehen weiterhin nur innerhalb des in `renovate.json` gesetzten `schedule` (Montag vor 6 Uhr).
### 5.2 Caching (`actions/cache@v6`)
`main.yaml`/`testing.yaml` cachen mehrere Verzeichnisse, um wiederholte Cross-Compile-Builds zu beschleunigen:
-`~/.cargo/registry`, `~/.cargo/git`, `target`– Cache-Key basiert auf `hashFiles('Cargo.lock')`.
-`~/.rustup/.../lib/rustlib/<target>` für die zwei zusätzlichen Cross-Targets – Cache-Key basiert auf der **aufgelösten**`rustc --version`, nicht auf dem gleitenden `stable`-Label. Sonst könnte nach einem Rust-Update eine veraltete gecachte Std-Lib mit einem neueren Compiler kombiniert werden.
-`~/.cargo/bin/cargo-binstall`, `~/.cargo/bin/cargo-deb`, `~/.cargo/bin/cargo-generate-rpm` (gezielt die Binaries statt des gesamten Verzeichnisses, um alte Rust-Compiler-Proxys bei Toolchain-Updates nicht wiederherzustellen) – alle drei sind auf feste Versionen gepinnt (Job-`env`), nicht auf `latest`.
**Wichtige Falle:**`target/debian`, `target/generate-rpm` und `target/arch` hängen ebenfalls unter `target` und werden dadurch mitgecacht, aber von keinem Tool automatisch geleert. Vor jedem Paketbau werden sie daher explizit per `rm -rf` bereinigt – sonst werden alte, bereits hochgeladene Paket-Dateien aus früheren Builds erneut mit hochgeladen, und die Gitea Package Registry lehnt sie mit `409 Conflict` ab (Paket-Dateien sind dort unveränderlich). Bei neuen Paketierungs-Outputs außerhalb dieser drei Ordner muss diese Bereinigung entsprechend erweitert werden.
Pro CI-Lauf wird genau **eine** Build-Nummer ermittelt und identisch an `cargo deb`, `cargo generate-rpm` und `package-arch.py --pkgrel` weitergereicht –`.deb`, `.rpm` und Arch-Paket tragen also immer dieselbe Nummer. Zur Ermittlung wird pro Paket-Typ (`debian`, `rpm`, `arch`) gezielt `GET /api/v1/packages/{owner}/{type}/{name}/-/latest` abgefragt (ein Request pro Typ, kein Paging, unbeeinflusst von Docker-Tags/anderen Paketen desselben Owners); das Maximum aller drei Typen + 1 ergibt die neue Nummer. Eine pauschale, ungefilterte Abfrage über alle Pakete des Owners (`GET /packages/{owner}`) darf hier nicht mehr verwendet werden, da sie durch Docker-Image-Tags & Co. verdrängt werden kann.
### 5.4 Secrets
-`PACKAGE_TOKEN` (bzw. Fallback-Token-Namen wie `RELEASE_TOKEN`, `GITEA_TOKEN`) wird für API-Zugriffe auf Gitea Packages, Container Registry und Releases verwendet.
-`SECURITY_TOKEN` für die Security-Scan-Workflows (Gitea-Issue-Erstellung).
-`RENOVATE_TOKEN` für den Renovate-Workflow.
-`GH_RENOVATE_TOKEN` (optional, Renovate-Workflow, als `GITHUB_COM_TOKEN` an Renovate durchgereicht) – GitHub-PAT (Public-Repo-Read genügt), damit Renovate Release-Infos für GitHub-gehostete Dependencies (u.a. `github-actions`-Manager) authentifiziert statt rate-limitiert abfragt.
### 5.5 Renovate (`renovate.json`)
-`baseBranches: ["dev"]`– Renovate liest Dependency-Dateien ausschließlich von `dev` und öffnet PRs nur dort, passend zum `dev → testing → main`-Promotion-Flow. Die Konfigurationsdatei selbst muss trotzdem über den Gitea-Default-Branch auffindbar sein.
- Drei Gruppen (`packageRules`), jeweils mit `separateMajorMinor: false`/`separateMinorPatch: false` (sonst reißt Renovate Major-Updates trotz `groupName` standardmäßig in einen eigenen PR): "Gitea Actions" (dateibasiert über `matchFileNames: [".gitea/workflows/**"]`, deckt auch die Custom-Manager unten ab), "Cargo Dependencies", "Docker-Images".
-`customManagers` (Regex) tracken Versionen, die als reine Strings in `run:`-Blöcken stecken und vom `github-actions`-Manager nicht erkannt werden: `TRIVY_VERSION`, `OSV_SCANNER_VERSION`, `TRUFFLEHOG_VERSION`, `CARGO_BINSTALL_VERSION`, `CARGO_DEB_VERSION`, `CARGO_GENERATE_RPM_VERSION`. Wird in einer Workflow-Datei eine weitere Tool-Version nach demselben Muster (`NAME_VERSION: "x.y.z"`) gepinnt, muss hier ein passender Eintrag ergänzt werden, sonst bleibt sie von Renovate unbemerkt veraltet.
Automatisiertes Werkzeug zum Extrahieren, Herunterladen und Spiegeln vorkompilierter Linux-Pakete aus GitHub-Releases in eine selbstgehostete Gitea- / Forgejo-Paket-Registry.
`mirror-package` überwacht konfigurierte GitHub-Repositories (wie z. B. `raspberrypi/rpi-imager` oder `Heroic-Games-Launcher/HeroicGamesLauncher`), identifiziert vorkompilierte Linux-Pakete (`.deb`, `.rpm`, `.pkg.tar.zst`, `.pkg.tar.xz`, `.pkg.tar.gz`, `.pacman`) und veröffentlicht diese anhand von Release-Stabilitätsregeln automatisch in den passenden Distributionen der Gitea-Paket-Registry.
├── docker-compose.example.yml # Beispielkonfiguration für Docker Compose
├── Cargo.toml # Projekt-Manifest und Paketierungs-Metadaten
├── renovate.json # Renovate-Konfiguration für automatisierte Abhängigkeits-Updates
├── LICENSE # GPL-3.0-or-later Lizenztext
├── AGENTS.md # Agenten- & Entwickler-Richtlinien
└── README.md # Projektdokumentation
@@ -248,6 +258,15 @@ cargo build --release
---
## CI/CD & Contributing
- **Branch-Flow**: Änderungen durchlaufen `dev` → `testing` → `main`, jeweils per Merge (nie direkt gepusht).
- **Pull Requests gegen `testing`** lösen automatisch `cargo test` aus.
- **Sicherheits-Scans**: Trivy & OSV-Scanner laufen bei Push auf `main`/`testing`/`dev` sowie bei jedem Pull Request; TruffleHog läuft bei Push auf **jeden** Branch (kein `branches`-Filter) sowie ebenfalls bei jedem Pull Request. Funde werden als Gitea-Issue gemeldet.
- **Abhängigkeits-Updates** werden automatisiert über [Renovate](https://docs.renovatebot.com/) als PRs gegen `dev` vorgeschlagen.
---
## Lizenz
Dieses Projekt ist unter der [GPL-3.0-or-later](LICENSE)-Lizenz lizenziert.
print(f"{', '.join(missing)} nicht gesetzt oder leer – überspringe Gitea-Issue-Synchronisation.")
else:
open_issue=find_open_issue(token,gitea_url,repo)
iffindings:
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.