Gitea Package Registry
Gitea, mein bevorzugtes System zum Verwalten von Quelltexten mit git, hat still und leise ein ganz wesentliches neues Feature erhalten. Das Add-On ist eine willkommene Ergänzung für alle, die neben Quellen auch daraus erzeugte Pakete oder Artefakte speichern müssen.
Wer Software erstellt, braucht einen Speicherplatz für die Quelltexte. Soweit ist das klar. Aber was, wenn die erstellte Software dann ein Python Modul ist, ein Ruby Gem oder ein NPM Paket? Ein Docker Image oder ein Maven Modul? Diese und weitere Pakettypen sind dazu gedacht, von Paketmanagern wie PIP, Rubygems und allen anderen nachgeladen zu werden, damit sie in weiteren Projekten verwendet werden können. Wenn eine Organisation also ein Mavon-Modul in Java schreibt, dann muss dieses auf eine Weise bereitgestellt werden, damit der Befehl mvn install das Paket finden und herunterladen kann.
Hier stehen Organisationen nicht selten vor einem Dilemma: Wohin mit den Artefakten? Kann ich mein internes Python-Modul öffentlich auf PyPI ablegen? Darf ich mein Docker-Image auf Docker Hub veröffentlichen, und kann ich dann mit den Limits beim Abruf leben? Wenn nicht, was ist die Alternative?
Das Ende Juli 2022 erschienene Gitea Release 1.17.0 bietet dafür das neue Feature “Package Registry” an. Pro Projekt lassen sich aktuell folgende Pakettypen unterstützen:
| Name | Language | Package client |
|---|---|---|
| Composer | PHP | composer |
| Conan | C++ | conan |
| Container | - | jeder OCI compliant client |
| Generic | - | jeder HTTP client |
| Helm | - | jeder HTTP client, cm-push |
| Maven | Java | mvn, gradle |
| npm | JavaScript | npm, yarn |
| NuGet | .NET | nuget |
| Pub | Dart | dart, flutter |
| PyPI | Python | pip, twine |
| RubyGems | Ruby | gem, Bundler |
| Vagrant | - | vagrant |
Package-Support aktivieren
Um das neue Feature zu verwenden, muss “Repository Packages Registry aktivieren” in der Sektion “Erweiterte Einstellungen” eines gitea-Projektes ausgewählt werden. Danach steht der Bereich “Pakete” in der Projektansicht neben Code, Releases und Aktivität bereit.
Docker-Images auf Gitea pushen
Danach kann die jeweilige Registry verwendet werden. Um Docker Images dort abzulegen, muss man sich zuerst mit docker login an der Registry anmelden, um dann mit docker push ein Image dort hochzuladen. Je nach Umgebung kann dieser Vorgang variieren, in meinem drone.io Buildskript schaut das so aus:
---
kind: pipeline
name: build
steps:
- name: docker
# See docs at https://plugins.drone.io/plugins/docker
image: plugins/docker
settings:
username: someuser
password: mysecretpassword
repo: git.software-berater.net/christian/software-berater.net
registry: git.software-berater.net
Auf diese Weise wird das Docker-Image für diese Webseite gebaut, und in die Registry geladen. Ja, der Registry-Name muss im Attribut repo erneut angegeben werden. Von dort kann ich es dann zB im Kontext von docker compose wieder verwenden:
---
version: '3'
services:
website:
image: git.software-berater.net/christian/software-berater.net:latest
Wie weiter?
Seit diesem Feature benötige ich keine zusätzliche, separate Registry mehr. Die vollständige Dokumentation dazu findet sich unter docs.gitea.io. Die neue Funktion ist zudem ein tolles Beispiel für die Kraft von offener Software - die Funktion wurde als Pull Request durch den Nutzer KN4CK3R bereitgestellt und dann gut 8 Monate lang von der Community kuratiert. Sogar die weitere Entwicklung ist schon geplant.
Für “programmierende Organisationen” bietet sich so die Möglichkeit, private Package Repositories einfach zu betreiben und den eigenen Workflow zu professionalisieren. Gut gemacht!