Da ich in meiner täglichen Arbeit regelmäßig mit GitLab-Releases und deren Artefakten zu tun habe, kenne ich das Problem nur zu gut: Man möchte schnell und reproduzierbar ein bestimmtes Release-Artefakt herunterladen – sei es in einem CI-Job, einem Skript oder einfach auf der Kommandozeile. Der GitLab-Browser ist dafür umständlich, und ein generisches curl-Kommando wird bei projekt-spezifischen URL-Strukturen schnell unhandlich. Ein kleines, dediziertes CLI-Tool wäre also genau das Richtige.
Dazu kommt, dass GitLab-Releases je nach Projekt sehr unterschiedlich aufgebaut sein können: Mal sind es CI-Job- Artefakte, mal Upload-Links, mal schlicht die Quellcode-Archive. Ein Tool, das diese verschiedenen Formate kennt und automatisch das Richtige tut, spart auf Dauer eine Menge Zeit. Gesagt, getan. Das hier vorgestellte Projekt ist genau das und bietet folgende Funktionen ✨:
- 📦 Download von Release-Artefakten und Quellcode-Archiven direkt über die GitLab API
- 🔗 Intelligente URL-Erkennung: CI-Job-Artefakte, Upload-Links und Quell-Archive werden automatisch erkannt und korrekt aufgelöst
- 🎯 Optionale Auswahl des Quellformats per -ext Flag (zip, tar.gz, tar.bz2, tar)
- ⚙️ Flexible Konfiguration: CLI-Flags oder Umgebungsvariablen (GITLAB_URL, GITLAB_TOKEN, HTTPS_PROXY)
- 🔒 Proxy-Unterstützung via Flag oder Umgebungsvariable
- 📊 Fortschrittsanzeige während des Downloads
- 🐳 Docker-Support – inklusive minimalem scratch-Image
- 🧪 Vollständige, hermetische Unit-Test-Suite (kein Netzwerk, kein echtes Dateisystem)
- 🧰 Cross‑platform builds für Linux, macOS und Windows
Architektur #
Das Projekt folgt dem Ports-&-Adapters-Muster (auch bekannt als Hexagonale Architektur), was die Testbarkeit deutlich vereinfacht. Die Kernlogik in internal/core/services/release_service.go kennt keine konkreten HTTP-Clients oder Dateisystem-Operationen – diese werden stattdessen als Interfaces injiziert und in Tests einfach durch Mocks ersetzt.
|
|
Natürlich ich Ports & Adapters ziemliches Overenginneering für so ein kleines Tool, aber so kann man das super üben und auch einmal Vor- und Nachteile veranschaulichen.
Verwendung #
Das Tool lässt sich nach einem einfachen go build direkt nutzen:
|
|
Für Releases mit mehreren Quellformaten lässt sich das gewünschte Format per Index auswählen – etwa tar.gz statt des Standard-Zips:
|
|
Und natürlich funktioniert der Download auch hinter einem Proxy:
|
|
Nutzung als Buildimag mit Podman #
Für den Einsatz in CI-Pipelines oder containerisierten Umgebungen gibt es zwei Dockerfiles: eines auf Alpine-Basis und eines mit einem minimalen scratch-Image, das nur das statisch gelinkte Binary enthält:
|
|
Genutzt werden kann das image dann:
|
|
Für mich hat sich das Tool bereits in mehreren Projekten bewährt und spart mir täglich ein paar Handgriffe. Wer ähnliche Workflows hat, ist herzlich eingeladen, es auszuprobieren und gerne auch beizutragen – Issues und Merge Requests sind willkommen!