Forgejo 17.0: Neue Actions-Funktionen, Support für 16.0 endet am 29. Oktober

Forgejo 17.0 ist seit dem 15. Oktober 2026 verfügbar. Für Betreiber einer Forgejo-Instanz mit Version 16 ist das mehr als eine Feature-Meldung: Laut offiziellem Release-Plan endet der Support für Forgejo 16.0 bereits am 29. Oktober 2026. Wer auf dem 16er-Zweig bleibt, bekommt danach keine Sicherheitsupdates mehr. Das Upgrade auf 17.0 gehört deshalb in ein Wartungsfenster der nächsten zwei Wochen, nicht in den Notfallmodus, aber auch nicht auf die lange Bank.

Gelassen bleiben können Instanzen auf Forgejo 15.0: Das ist die aktuelle LTS-Version mit Support bis 15. Juli 2027. Forgejo 17.0 selbst ist keine LTS-Version und wird nur bis 28. Januar 2027 gepflegt. Die nächste LTS-Version 19.0 ist für April 2027 geplant.

Was ist neu in Forgejo 17.0?

Das Forgejo-Projekt hat Version 17.0.0 laut Codeberg-Release am 15. Oktober 2026 veröffentlicht, die Ankündigung im Projektblog trägt dasselbe Datum. Die wichtigsten Neuerungen:

• Job Summaries: Forgejo zeigt Zusammenfassungen an, die Workflows als Markdown in die Datei $FORGEJO_STEP_SUMMARY schreiben. Aus Kompatibilitätsgründen funktioniert auch $GITHUB_STEP_SUMMARY. Voraussetzung ist Forgejo Runner 13.2 oder neuer.
• Actions-API: Abgeschlossene Workflow-Läufe und einzelne Jobs lassen sich per API neu starten, Job-Logs können gefiltert, schrittweise und als NDJSON abgerufen werden.
• Git LFS: Die Unterstützung wird grundlegend überarbeitet. Neu sind unter anderem eine Ansicht der Commits, die auf eine LFS-Datei verweisen, und eine bessere Behandlung von Pointern.
• Migration aus Bitbucket Data Center (früher Bitbucket Server) inklusive Pull Requests, Reviews und Kommentaren.
• Einladungen in Organisationen statt sofortiger Aufnahme, aktivierbar mit [service].ADD_MEMBERS_BY_INVITATIONS = true in der app.ini. Einladungen laufen standardmäßig nach 14 Tagen ab.

Für wen ist das relevant?

Relevant ist die Version für alle, die Forgejo selbst betreiben. Die Dringlichkeit hängt vom eingesetzten Zweig ab:

• Forgejo 16.x: Handlungsbedarf bis 29. Oktober 2026. Danach endet der Support, ein Upgrade auf 17.0 ist der vorgesehene Weg.
• Forgejo 15.x LTS: kein Zwang. Die LTS-Version bleibt bis Juli 2027 unterstützt und hat am 12. Oktober mit 15.0.10 noch Sicherheitskorrekturen erhalten.
• Ältere Versionen ab 14.x und darunter: Diese Zweige sind laut Release-Seite eingestellt. Hier ist ein Upgrade ohnehin überfällig.

Nicht betroffen ist, wer Codeberg oder eine andere gehostete Forgejo-Instanz nur als Nutzer verwendet. Dort entscheidet der Betreiber über das Upgrade.

Breaking Changes vor dem Upgrade prüfen

Die Release Notes listen mehrere Änderungen, die bestehende Installationen verändern können. Für Admins sind vor allem diese Punkte wichtig:

• Absolute Links in gerenderten Dokumenten, also Links mit führendem /, beziehen sich jetzt auf das Wurzelverzeichnis des Repositories statt auf die Wurzel der Instanz. In Issues, Pull Requests und Kommentaren bleibt es beim bisherigen Verhalten. README-Dateien mit solchen Links sollten nach dem Upgrade stichprobenartig geprüft werden.
• Zeitangaben in der Konfiguration werden strikt geparst. Ein ungültiger Wert ungleich null wird nicht mehr stillschweigend toleriert.
• Die Standard-Logdatei heißt jetzt forgejo.log. Für Rückwärtskompatibilität legt Forgejo einen Symlink gitea.log an, wenn kein eigener Dateiname konfiguriert ist. Logrotate- und Monitoring-Regeln sollten auf den neuen Namen zeigen.
• JWTs müssen standardmäßig einen exp-Claim enthalten. Zugleich lassen sich mit JWT_KEYS_ACCEPTED im Abschnitt [oauth2] Signaturschlüssel ohne Unterbrechung rotieren.
• Die Webhook-Ereignisse für Action Runs sind als veraltet markiert und werden durch die Workflow-Run-Ereignisse ersetzt. Eine automatische Migration gibt es nicht, weil sich Header und der Schlüssel action geändert haben. Bestehende Empfänger können dadurch brechen.

Sicherheitskorrekturen in 17.0 und 16.0.6

Forgejo 17.0.0 enthält laut Release Notes Sicherheitskorrekturen, die zuvor auch in die gepflegten Zweige zurückportiert wurden. Dazu gehört ein Fehler beim Anlegen von Tags über die Release-API, bei dem nicht zugehörige Metadaten von Release-Anhängen geladen und in der API-Antwort zurückgegeben werden konnten. Ebenfalls enthalten ist eine früher veröffentlichte Korrektur für Anhänge von Entwurfs-Releases, die Nutzer mit Leserecht abrufen konnten. Hinzu kommen als Sicherheitsupdates gekennzeichnete Abhängigkeiten wie die Go-Toolchain 1.26.9.

Wer bis zum Upgrade auf 16.x bleibt, sollte mindestens 16.0.6 vom 12. Oktober einsetzen, auf dem LTS-Zweig 15.0.10 vom selben Tag. Beide Versionen beheben unter anderem einen Fehler, durch den Workflows mit den Ereignissen pull_request_review und pull_request_review_comment aus Forks ohne die übliche Freigabe und mit Zugriff auf Secrets laufen konnten. Für Instanzen mit öffentlichen Repositories und Forgejo Actions ist das wichtiger als jede neue Funktion. Eine eigene CVE-Nummer nennen die Release Notes dazu nicht.

Docker-Image-Tags und Upgrade-Weg

Die Container-Images liegen unter codeberg.org/forgejo/forgejo, als Spiegel dient data.forgejo.org. Eine Abfrage der Registry am 17. Oktober zeigt: Die Tags 17, 17.0 und 17.0.0 verweisen auf denselben Digest, die Rootless-Variante heißt 17-rootless. Einen Tag latest gibt es nicht. Wer bisher :16 pinnt, wird also nicht automatisch auf 17 gehoben. Das ist gewollt: Laut Dokumentation erfordert ein Wechsel der Hauptversion einen manuellen Schritt mit Prüfung. Wer künftig nur Patch-Releases automatisch beziehen will, pinnt 17.0.

Das Upgrade selbst besteht laut Projekt aus dem Austausch von Binary oder Container-Image. Die Upgrade-Anleitung verlangt vor einem Wechsel der Hauptversion ein vollständiges Backup und empfiehlt danach forgejo doctor check --all --log-file /tmp/doctor.log.

Was sollten Admins jetzt tun?

• Version und Zweig prüfen: im Adminbereich unter Site Administration oder per forgejo --version, bei Containern den gepinnten Image-Tag in der Compose-Datei.
• Auf 16.x sofort 16.0.6 einspielen und das Upgrade auf 17.0 vor dem 29. Oktober 2026 einplanen.
• Vor dem Upgrade ein vollständiges Backup erstellen, inklusive Datenbank, Repositories, LFS-Daten und app.ini mit den Secrets.
• Webhook-Empfänger für Action-Run-Ereignisse inventarisieren und auf Workflow-Run-Ereignisse umstellen, sobald die Empfänger das neue Format verarbeiten.
• Logrotate, Log-Shipping und Monitoring auf forgejo.log anpassen, Zeitangaben in der app.ini auf gültige Werte prüfen.
• Forgejo Runner auf 13.2 oder neuer aktualisieren, wenn Job Summaries genutzt werden sollen.
• Nicht nötig ist ein Wechsel von 15.x LTS auf 17.0, wenn keine der neuen Funktionen gebraucht wird.

Passende Anleitungen auf S-EDV

• Forgejo nativ auf Ubuntu installieren: Installation mit Binary, systemd, Nginx und MariaDB, hilfreich für den Binary-Austausch beim Upgrade.
• Forgejo schließt kritische Codeausführungslücke in Vorlagen-Repositories: Hintergrund zu den Sicherheitsupdates 16.0.4 und 15.0.8 vom September.
• Woodpecker CI per Docker betreiben: eine Alternative für Teams, die CI getrennt von der Git-Plattform betreiben möchten.

Quellen

• Forgejo-Blog: Forgejo v17.0 is available (15.10.2026)
• Forgejo Release Notes 17.0.0 auf Codeberg
• Forgejo Release Notes 16.0.6 auf Codeberg
• Forgejo-Releaseübersicht mit Supportzeiträumen
• Forgejo-Dokumentation: Upgrade-Anleitung für v17.0
• Linuxiac: Forgejo 17.0 mit verbesserten Actions und LFS-Unterstützung