Forgejo v16.0 veröffentlicht — Benachrichtigungen, PR-Reviews und Actions erweitert

 (forgejo.org)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Forgejo v16.0, veröffentlicht am 16. Juli 2026, erweitert die Benachrichtigungssteuerung pro Repository, den Migrationsfortschritt, Pull-Request-Reviews sowie Actions- und API-Funktionen
  • Durch das Blockieren von HTTP-Weiterleitungen bei Git-Mirrors wurde der SSRF-Schutz verstärkt; bei umbenannten Remote-Repositories oder solchen mit geändertem Besitzer muss die Mirror-Adresse manuell aktualisiert werden
  • Wenn in Containern Authentifizierung über einen Reverse Proxy verwendet wird, muss jetzt der vertrauenswürdige Proxy-Adressbereich angegeben werden; einige bestehende Konfigurationen, bei denen der Standard-Webport einem nicht vertrauenswürdigen Netzwerk ausgesetzt ist, funktionieren nicht mehr
  • Hinzugekommen sind mehrzeilige Reviews, Kommentarpositionsverfolgung auf Basis von git blame --reverse, Ausführungsprioritäten für Actions, JWT-basierte Authorized Integrations sowie APIs für Workflow-Logs, Artefakte und Abbruch
  • v16.0 ist ein Nicht-LTS-Release, das bis zum 29. Oktober 2026 unterstützt wird; vor dem Upgrade sollten ein vollständiges Backup erstellt und alle Kompatibilitätsänderungen geprüft werden

Veröffentlichung und Upgrade

Kompatibilitätsänderungen und Sicherheitsverbesserungen

  • SSRF-Schutz für Git-Mirrors

    • Ein Problem wurde behoben, durch das [migrations].ALLOWED_DOMAINS, LOCKED_DOMAINS und ALLOW_LOCALNETWORKS in einigen Ausnahmefällen nicht korrekt angewendet wurden
    • Damit Git beim Zugriff auf HTTP(S)-Repositories Weiterleitungen nicht verfolgen und so Einstellungen umgehen kann, wird http.followRedirects=false gesetzt
    • Bei entfernten Forgejo-Repositories, die umbenannt oder auf einen neuen Besitzer übertragen wurden, werden Weiterleitungen jetzt als Fehler behandelt; bestehende Mirrors müssen daher auf die neue Repository-Adresse aktualisiert werden

  • Entfernen der EXIF-Bereinigung für Avatare

    • Die in v13.0 eingeführte Funktion zum Entfernen von EXIF-Metadaten aus Avatar-Bildern wurde wegen eines Lizenzproblems entfernt, da versehentlich eine AGPL-Bibliothek verwendet wurde
    • Bis eine andere Implementierung geprüft ist, wurde die Funktion entfernt, um die Lizenzkonformität wiederherzustellen

  • Konfiguration vertrauenswürdiger Proxys in Containern

    • Bisher nutzten Forgejo-Container standardmäßig REVERSE_PROXY_TRUSTED_PROXIES = *
    • Wenn alle folgenden Bedingungen erfüllt waren, konnten nicht autorisierte Benutzer über den Header X-WebAuth-User andere Benutzer imitieren
      • Bereitstellung in einem Docker- oder Podman-basierten Container
      • Konfiguration mit [service].ENABLE_REVERSE_PROXY_AUTHENTICATION=true
      • Der Standardwert * von [security].REVERSE_PROXY_TRUSTED_PROXIES wurde nicht geändert
      • Der Standard-Webport :3000 war einem nicht vertrauenswürdigen Netzwerk ausgesetzt und erlaubte so die Umgehung des authentifizierenden Reverse Proxys
    • v16 akzeptiert Reverse-Proxy-Konfigurationen dieser Art nicht mehr; stattdessen muss der Adressbereich vertrauenswürdiger Proxys für eingehenden Traffic explizit angegeben werden
    • Ein Beispiel für die Umgebungsvariable ist FORGEJO__security__REVERSE_PROXY_TRUSTED_PROXIES=127.0.0.0/8,::1/128,172.16.X.X/X
    • In app.ini wird dieselbe Adressliste unter [security] bei REVERSE_PROXY_TRUSTED_PROXIES gesetzt

Nutzbarkeit für Repositorys und Organisationen

  • Repository-Benachrichtigungen können in drei Kategorien abonniert werden: Issues, Pull requests, Releases
    • Das neu gestaltete Benachrichtigungs-Backend bildet die Grundlage für künftig noch feinere Einstellungen
    • Ziel ist es, Benutzern Kontrolle über Benachrichtigungen zu geben, ohne sie mit zu vielen Optionen zu überfordern
  • Der Bildschirm für Repository-Migrationen zeigt den Fortschritt beim batchweisen Übertragen von Issues und Pull Requests aus der Quelle an, sodass erkennbar ist, ob lang laufende Vorgänge stillstehen
    • Die Standard-Batchgröße beträgt 45, und auch die Mindestanzahl von Elementen für eine Fortschrittsanzeige liegt bei 45
  • Für Stellen, an denen keine volle Größe benötigt wird, werden zwei verkleinerte Avatar-Varianten erzeugt, um Bandbreitennutzung und Ladezeit zu reduzieren
  • In der Mitgliederliste einer Organisation kann direkt ein Dialog geöffnet werden, um neue Mitglieder hinzuzufügen und sie mehreren Teams gleichzeitig zuzuweisen
  • Git prüft jetzt mehrere Inkonsistenzen bei empfangenen Objekten und weist sie zurück, um zu verhindern, dass ein Repository in einen inkonsistenten oder beschädigten Zustand gerät
  • Im Backend-Repository werden keine Git-Beispiel-Hook-Dateien mehr erzeugt, und instanzweite gemeinsame Git-Hooks werden nicht mehr pro Repository kopiert, sondern zentral gespeichert
    • Das spart etwa 20 KiB pro Repository
    • Beispiel- und duplizierte automatisch erzeugte Dateien in bestehenden Repositorys können gemäß dem Upgrade-Leitfaden gelöscht werden
  • Ein seit v7.0.0 bestehender Bug, durch den neuen Benutzern kein Hinweis zur stärkeren Nutzung von Repository-Funktionen angezeigt wurde, wurde behoben; außerdem ist die Einstellung zum Deaktivieren des Hinweises leichter auffindbar
    • Der Hinweis „Enable more“ erscheint nur noch, wenn Administratoren oder Repository-Besitzer bestimmte Repository-Funktionen ausdrücklich deaktiviert haben

Pull Requests und Code-Review

  • Die Commit-Liste auf der Pull-Request-Seite wurde auf ein neues Layout umgestellt, das besser lesbar ist und besser auf verschiedene Bildschirmgrößen reagiert
    • Derzeit gilt dies nur für die Pull-Request-Seite; eine schrittweise Ausweitung auf andere Commit-Listen ist geplant
  • Unterstützt werden jetzt mehrzeilige Reviews, bei denen mehrere geänderte Zeilen mit einem einzigen Review-Kommentar verknüpft werden
    • Wenn Shift gedrückt gehalten wird, kann mit dem Plus-Button neben der ersten Zeile begonnen und bis zur letzten Zeile gezogen werden, sodass die ausgewählten Zeilen einem Kommentar zugeordnet werden
  • Probleme, bei denen Review-Kommentare im falschen Diff oder an der falschen Bildschirmposition erschienen oder die Diff-Verknüpfung verloren, wurden behoben
    • Bisher konnte git blame die Position falsch bestimmen, wenn der kommentierte Code in späteren Commits verschoben wurde
    • Intern wird nun git blame --reverse verwendet, um Codeänderungen bis zu ihrer aktuellen Position nachzuverfolgen
    • Die Kommentarposition wird nicht nur anhand des HEAD des aktuellen Pull Requests berechnet, sondern anhand von Base und Head, die der Reviewer tatsächlich ansieht, sowie anhand des Commits des gerade angezeigten Codes
    • Gelöschte Zeilen werden anhand des Zeitpunkts ihrer Löschung ermittelt und zusätzlich darauf geprüft, ob sie an derselben Stelle im aktuellen Diff ebenfalls gelöscht sind; danach wird der Kommentar platziert oder als veraltet markiert

Forgejo Actions und JWT-Integration

  • Ausführungsprioritäten und Workflow-Verwaltung

    • Einzelne Workflow-Ausführungen können manuell als vorrangig markiert werden; Forgejo Actions verarbeitet sie dann vor normalen Ausführungen
    • Wo möglich, wertet Forgejo if-Bedingungen direkt selbst aus und sendet Jobs nicht an Forgejo Runner, wodurch Ausführungen schneller starten können
    • Abgeschlossene Workflow-Ausführungen sowie Logs und Artefakte können über die UI oder die HTTP-API gelöscht werden
      • Löschen dürfen nur Repository-Administratoren oder Access Tokens mit der Berechtigung write:repository
    • cron-Ausdrücke unterstützen neben dem bisherigen Format CRON_TZ jetzt auch die GitHub-typische Syntax zur Zeitzonenangabe
    • Übersprungene Checks, die in früheren Versionen als erfolgreich angezeigt wurden, werden ab v16 als skipped markiert

  • Authorized Integrations

    • Nachdem v15 bereits das Erzeugen von JWTs für externe Systeme zur Authentifizierung eingeführt hatte, bietet v16 nun Authorized Integrations, die JWTs zur Authentifizierung gegenüber der Forgejo-API und beim Git-Zugriff verwenden
    • Sie können lokal in Forgejo Actions verwendet werden, oder es können Regeln konfiguriert werden, damit Forgejo beliebige JWTs validiert
    • Wenn Zugriff über die normalen Rechte von ${{ forgejo.token }} hinaus benötigt wird, kann ein statisches Access Token eingerichtet werden, ohne dass es künftig rotiert werden muss
    • Funktionen, mit denen Workflow-Autoren sich selbst unerwartete Berechtigungen geben könnten, werden nicht offengelegt
    • Die Nutzung ist über mehrere Forgejo-Repositories hinweg möglich
    • Externe Systeme, die die technischen Voraussetzungen erfüllen, können über die Authorized Integration eines Benutzers ohne systemübergreifende statische Geheimnisse direkt auf die Forgejo-API und Git-Repositories zugreifen
      • Beispiele sind Amazon Web Services, GitHub Actions und GitLab CI/CD

Actions und Verwaltungs-API

  • Es wurde eine API zum Abrufen von Logs für komplette Workflow-Ausführungen oder einzelne Jobs hinzugefügt
  • Es gibt Endpunkte zum Auflisten, Herunterladen und Löschen von Artefakten
    • Ein dokumentierter Endpunkt zum Hochladen von Artefakten bleibt als künftige Aufgabe offen
  • Es wurde eine API zum Abbrechen einzelner Workflow-Ausführungen hinzugefügt
  • /actions/run gibt Informationen zur Workflow-Ausführung zurück, zu der das automatische Token FORGEJO_TOKEN gehört
  • Weitere API-Änderungen sind unter anderem:
    • Den Organisationsmodellen, die von mehreren Endpunkten zurückgegeben werden, wurde die Erstellungszeit hinzugefügt
    • Bei der Suche nach Pull Requests kann nach Base- und Head-Branch-Namen gefiltert werden
    • Instanzadministratoren können Benutzer-Access-Tokens auflisten, ausstellen und löschen
    • Benutzerlisten können nach dem 2FA-Status gefiltert werden

Supportzeitraum und Test-Builds

  • Größere Releases erscheinen alle drei Monate; Patch-Releases werden je nach Schwere der enthaltenen Fehlerbehebungen oder Sicherheitsfixes häufiger bereitgestellt
  • v16.0 ist ein Nicht-LTS-Release und wird bis zum 29. Oktober 2026 unterstützt
    • v11.0 LTS erreicht am 16. Juli 2026 das Support-Ende
    • v15.0 LTS wird bis zum 15. Juli 2027 unterstützt
    • v17.0 soll am 15. Oktober 2026 erscheinen und bis zum 28. Januar 2027 unterstützt werden
  • Aus den neuesten Änderungen des Entwicklungszweigs v16.0/forgejo werden tägliche Builds 16.0-test erzeugt und auf der Testinstanz bereitgestellt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Lobste.rs

  • @pushcx, wo ist der Suggest-Link geblieben? Ich wollte das Tag vcs vorschlagen, aber jetzt sehe ich den Link bei keinem Beitrag mehr

    • Mir geht es genauso, und ich würde gern wissen, warum
    • Bei diesem Beitrag und den meisten Beiträgen auf der Startseite sehe ich derzeit den Suggest-Link, und unter https://lobste.rs/moderations gibt es auch keine Maßnahmenhistorie für dein Konto. Sieht nach einem Bug aus

  • Danke an alle Beitragenden, besonders an das Merge-Team. Persönlich bin ich stolz darauf, zu dem Fix unter https://forgejo.org/2026-07-release-v16-0/#repository-units-hint beigetragen zu haben

  • Ich habe in den letzten Tagen unter https://forge.l3x.in einen persönlichen Forge eingerichtet und angepasst und bin schrittweise von GitHub migriert; Forgejo selbst zu hosten war eine sehr zufriedenstellende Erfahrung, die ich ausdrücklich empfehlen kann
    Ich habe gehört, dass SourceHut ebenfalls gut sein soll, habe es aber nicht selbst ausprobiert und konzentriere mich derzeit auf Forgejo

  • Die Funktionen für mehrzeilige Reviews und das Positionieren von Review-Kommentaren sind erfreulich. Bei $JOB gibt es keine Code-Reviews, daher bin ich damit nicht vertraut; beim Review meiner Patches für freie und Open-Source-Projekte habe ich ein paar Mal falsch verstanden, auf welchen Codeblock sich ein Kommentar bezog

  • Auf feingranulare Abo-Einstellungen freue ich mich sehr. Das war eine Funktion, die ich von GitHub kannte und in Forgejo schmerzlich vermisst habe
    Auch bei GitHub wünsche ich mir schon lange eine Funktion, mit der man Issues und PRs beim Neuerstellen abonnieren kann. So könnte man die Entwicklung von Projekten verfolgen, zu denen man nur gelegentlich beiträgt, ohne 90 % der uninteressanten Benachrichtigungen einzeln abzubestellen
    Ich habe im Forgejo-Repository einen Feature-Request erstellt: https://codeberg.org/forgejo/forgejo/issues/13494

  • Ich betreibe Forgejo schon seit einiger Zeit in meinem Homelab und bin sehr zufrieden. Ich habe etwa 500 Repositories migriert, die zuvor auf Github.com lagen; der Prozess war kaum umständlich, und Forgejo samt Runner läuft bei mir in k8s
    Besonders praktisch war, dass der Forgejo Runner dieselben Workflow-Definitionen wie GitHub Actions verwendet; ich musste nur die richtigen Labels für den lokalen Runner anlegen
    Ich habe noch nicht entschieden, ob ich GitHub read-only beibehalte, lösche oder als gleichwertigen Mirror weiterführe. So oder so pushe ich jetzt direkt auf meine Forgejo-Instanz statt auf GitHub, und alles ist um Größenordnungen schneller, im Bereich von Sekunden