Persönliche Builds mit Jenkins CI ohne SCM

Question

Ich bin gespannt, ob es möglich ist, Jenkins CI ohne SCM zu verwenden, um es Entwicklern zu ermöglichen, remote persönliche Builds auszuführen. Ich verstehe, dass der typische Anwendungsfall darin besteht, einen Build zu autotriggern, sobald Änderungen in SCM geprüft werden. Ich frage mich, ob es Leute gibt, die Jenkins ohne SCM benutzen?

Grundsätzlich stelle ich mir vor, dass der Entwickler seinen geänderten Code in ein Verzeichnis auf einem Server hochladen und dann manuell einen Build auslösen soll (z. B. über ein kleines Web-Frontend), indem er den Speicherort des hochgeladenen Codes eingibt. Dies sollte der Ausführung eines lokalen Builds auf einem Entwicklungscomputer ähneln. Vorzugsweise sollte es auch die Möglichkeit geben, einige Build-Schritte oder Tests wegzulassen, da sie für einige Änderungen nicht immer notwendig sind.

Mit einem Versionskontrollsystem wie git würde dies wahrscheinlich getan werden, indem Entwickler ihre experimentellen Änderungen in separaten Zweigen einchecken, bevor sie in den Masterzweig integriert werden. Leider haben wir kein Versionskontrollsystem, das einfach allgegenwärtige Verzweigungen ermöglicht. Daher frage ich nach einer Lösung, bei der der Entwickler sein lokales Arbeitsbereichsverzeichnis auf den Jenkins-Server hochlädt, um zu prüfen, ob der Build erfolgreich ist, bevor er seine Änderungen an der Leitung festschreibt.

Alle Vorschläge werden sehr geschätzt.

Answer 1

Der einfachste Weg, um dies zu erreichen, ist ein parametrisiertes Jenkins-Projekt mit einem Dateiparameter zu erstellen und Ihre Entwickler verwenden, um eine Zip-Datei hochzuladen, die alles enthält, was getestet werden muss Entpacken Sie das Build, führen Sie die Tests aus und melden Sie den Projektstatus.

Die Schritte des Projekts würde im Wesentlichen sein:

• Überprüfen Sie die This project is parameterized Checkbox
  • Wählen File Parameter aus dem Drop-down und füllen Sie die erforderlichen Felder aus.
• Fügen Sie einen weiteren Parameter hinzu (Typ hängt davon ab, wie Sie es tun), der Tests angibt, die ignoriert werden sollen.
• Löschen Sie den vorherigen Test Build
• Verwenden Sie 7-Zip oder ähnliches, um die hochgeladene Datei zu entpacken.
• Führen Sie alle Tests durch und notieren Sie den Build-Status.

Dann, wenn ein Benutzer einen Build beginnen will, könnten sie zip ihrem Verzeichnis nach oben gehen Sie einfach auf das Jenkins-Projekt, das Build with parameters klicken, laden Sie die Datei, und weg würde es gehen. Solange gleichzeitige Builds deaktiviert sind (ich glaube, die neuesten Versionen von Jenkins deaktivieren sie standardmäßig, aber ich weiß es nicht sicher), denke ich, dass dies Ihre Bedürfnisse erfüllen würde, und jede Build-Warteschlange für die Ausführung wie Sie aufgebaut wollen.

---

Als beiseite, und ich weiß, das ist sehr viel nicht Ihre Frage, wenn Sie verwenden git tat, sie so etwas wie this process Jenkins nutzen könnten, um nur schieben Änderungen an den Stable-Zweig, die erfolgreich gewesen gebaut.