For English version see the English version of this article.
 
VersionEye hilft Entwicklern dabei, die in Projekten verwendeten Komponenten und Abhängigkeiten aktuell zu halten. Es kann dabei selbstständig Projekte in öffentlichen GitHub und Bitbucket-Repositories überwachen. Kommen allerdings private Repositories oder firmeninterne Repository-Server zum Einsatz, so müssen die Paketmanager-Dateien normalerweise manuell auf die VersionEye-Plattform hochgeladen werden.
 
Diesen Schritt vereinfacht das npm-Modul versioneye-update, indem es den Upload über die Kommandozeile erledigen kann; somit kann dieses Tool auch in Continuous-Integration-Systemen wie beispielsweise Jenkins eingesetzt werden.
Wir nutzen dies bei unseren Kundenprojekten, um bei jedem Jenkins-Build die Paketmanager-Datei auf VersionEye zu aktualisieren. So haben wir stets einen guten Überblick, in welchem Projekt welche Komponente aktualisiert werden sollte. (Zur ausführlichen Beschreibung)
 
„versioneye-update“ gibt es seit kurzem in der neuen Version 1.4 mit einigen neuen Features:

  • Unterstützung der global installierten Pakete,
  • Anlegen von VersionEye-Projekten und
  • Konfigurationsdateien.

 

Global installierte Pakete

Mit npm gibt es nicht nur die Möglichkeit, npm-Module in Projekten zu verwenden, sondern npm-Module können mit dem Parameter "-g" auch global installiert werden; sie stehen damit systemweit zur Verfügung. Prominente Beispiele dafür sind „grunt“, „eslint“ oder auch „npm“ selbst.
 
Für solche global installierte Pakete gab es bisher keine Überwachung und Benachrichtigung für neuere Versionen. „versioneye-update“ kann mit der Version 1.4 nun auch eine Liste dieser global installierten npm-Module erstellen und als Paketdatei an VersionEye übermitteln. Sollte eine neue Version der global installierten Pakete veröffentlicht werden, so wird VersionEye eine Benachrichtigung versenden.
 
Die Verwendung ist folgendermaßen:
Zunächst muss einmalig ein Projekt auf VersionEye angelegt werden, das die global installierten npm-Module aufnimmt. Dazu wird eine „Pseudo“-package.json erstellt und auf VersionEye hochgeladen, dazu dient folgender Befehl:
$ versioneye-update --apikey <APIKEY> --createproject --globalinstalls
Damit wird ein Projekt auf VersionEye angelegt und im aktuellen Arbeitsverzeichnis eine Datei ".versioneye-update.json" erstellt, in der die Projekt-ID für das eben erstellte Projekt hinterlegt wird.
Zukünftig aktualisiert der folgende Befehl die Liste der global installierten Pakete auf VersionEye:
$ versioneye-update --apikey <APIKEY> --globalinstalls
 
Am besten automatisiert man diese Aufgabe, indem man direkt einen automatischen Task anlegt (cron-job unter Linux oder Geplanter Task unter Windows), der regelmäßig, bspw. einmal pro Woche, das VersionEye-Projekt aktualisiert.
So kann man sich sicher sein, dass man eine Benachrichtigung erhält, sobald es für ein oder mehrere der globalen npm-Module auf diesem Rechner eine Aktualisierung gibt.

 

Neue VersionEye-Projekte anlegen

Mit der Version 1.4 von „versioneye-update“ können VersionEye-Projekte nicht nur aktualisiert sondern auch angelegt werden. Dazu verwendet man den Parameter "--createproject". Dabei wird nicht geprüft, ob es das Projekt bereits in VersionEye gibt!
(Hinweis: Die Möglichkeit, Projekte über die Webschnittstelle anzulegen, hängt vom gewählten Bezahlmodell ab, nicht alle Modelle erlauben dies!)
Wird ein neues Projekt angelegt, so erzeugt „versioneye-update“ automatisch auch eine ".versioneye-update.json"-Datei, in der Konfigurationsparameter hinterlegt sind, bspw. die Projekt-Kennung. Aus Sicherheitsgründen wird der API-Schlüssel niemals durch „versioneye-update“ in diese Datei geschrieben.
Die Datei kann zusammen mit dem Projekt in ein Versionskontrollsystem/Repository aufgenommen werden; das ist empfehlenswert, da die Projektkennung für alle Entwickler gleich ist und immer direkt mit dem Projekt abgelegt werden sollte und so beispielsweise auch in einem Jenkins-Job verwendet werden kann.
Neue VersionEye-Projekte können sowohl für Paketmanagerdateien (die über "--file" angegeben werden) wie auch für global installierte Pakete (wenn "--globalinstalls" verwendet wird) angelegt werden. Im regulären Modus wird die Datei in dem Verzeichnis gespeichert, in dem sich auch die Paketmanagerdatei befindet; im Modus für die global installierten Pakete wird die ".versioneye-update.json"-Datei im aktuellen Arbeitsverzeichnis abgelegt.
Hinweis: Existiert die Datei bereits vor dem Aufruf von „versioneye-update“ mit "--createproject" und enthält diese Datei bereits eine Projekt-ID, so führt dies zu einem Fehler und der Vorgang wird abgebrochen.

 

Konfigurationsdateien

Mit der aktuellen Version unterstützt „versioneye-update“ Konfigurationsdateien. Diese wird beim Anlegen eines Projekts automatisch angelegt oder kann von Hand angelegt werden: es handelt sich dabei um eine Datei im JSON-Format, in der Kommandozeilenparameter aufgelistet sind. Dabei können genau die gleichen Parameter verwendet werden, die auch auf der Kommandozeile verwendet werden.

{
   "projectid": "12345abcdef12345abcdef12",
   "listoutdated": true,
   "dump": true,
   ...
}

 
Zuerst wird die Datei ".versioneye-update.json" im Home-Verzeichnis des Benutzers ausgelesen, wenn vorhanden. Üblicherweise enthält diese den API-Key und ist über Dateisystemmechanismen vor unberechtigtem Zugriff geschützt.
Im regulären Modus wird anschließend die Datei ".versioneye-update.json" im Verzeichnis der Paketmanagerdatei ausgelesen, im globalen Modus wird die Datei ".versioneye-update.json" aus dem aktuellen Arbeitsverzeichnis gelesen, wenn sie vorhanden ist. Angaben in dieser Datei überschreiben die Angaben der Datei aus dem Home-Verzeichnis.
Anschließend werden die Kommandozeilenparameter interpretiert. Angaben über die Kommandozeilen überschreiben alle aus den Dateien geladenen Konfigurationseinstellungen.
Mit diesem flexiblen Konzept können die Einstellungen, die für alle Projekte gelten, im Home-Verzeichnis des Benutzers abgelegt werden, besonders sinnvoll ist dies natürlich für den API-Schlüssel.
Alle projektspezifischen Einstellungen wie die Projekt-ID oder ob Lizenzverletzungen zu einem Fehler während der Ausführung des Jenkins-Jobs führen, werden in der projektspezifischen Datei gespeichert.
 
Das npm-Modul ist Open-Source und kann frei eingesetzt werden. Der Quelltext liegt im öffentlichen GitHub-Repository von Onwerk, dort gibt es auch die Installationsanleitung.
 
Alle Beiträge im Blog zu versioneye-update