Jenkins & Bitbucket; Vorherigen Build abbrechen, wenn ein neues Commit für denselben Zweig vorgenommen wurde?

Wir lassen Jenkins Unit-Tests durchführen, wenn Commits für unser Repo in Bitbucket vorgenommen werden. Dies wird vom Bitbucket-Plugin gesteuert, dh über einen Bitbucket-Webhook.

Derzeit wird ein Unit-Test gestartet, wenn ein Commit für Zweig A vorgenommen wird. Wenn während der Ausführung dieses Jobs ein zweites Commit für Zweig A durchgeführt wird, wird ein zweiter Komponententest gestartet. Daher gibt es jetzt zwei Komponententests für denselben Zweig, jedoch mit leicht unterschiedlichem Code.

Unser bevorzugtes Verhalten ist, dass der Test des ersten Commits abgebrochen wird, wenn der zweite Test gestartet wird, sodass nur der letzte Komponententest ausgeführt wird. Kann das erreicht werden?

Zu klären; Wir haben viele Zweige, so dass wir nicht einfach gleichzeitige Builds verhindern, den letzten abbrechen können, sobald der nächste startet usw. Unabhängig von der verwendeten Methode muss speziell geprüft werden, ob für den Zweig bereits ein Job ausgeführt wird, und nicht, ob der Job im Allgemeinen bereits ausgeführt wird Laufen.

Ich habe einige Trigger-Steuerelemente für Git gesehen, aber nicht Bitbucket. Ich habe auch ein Skript gefunden, um zu überprüfen, ob der Job bereits ausgeführt wird, und ihn gegebenenfalls abzubrechen, aber wie bereits erwähnt, passt dies nicht zu unserem Anwendungsfall. Vermisse ich etwas

Hinweis: Diese Antwort stammt aus meinem Hintergrund beim Erstellen benutzerdefinierter Lösungen. Es handelt sich nicht nur um eine Konfiguration, die, falls verfügbar, offensichtlich vorzuziehen wäre. Aber es ist vielleicht etwas anderes zu beachten.

Sie können dem Skript, das den Komponententestjob ausführt, beibringen, einen Ausführungsstatus pro Zweig beizubehalten.

Wenn das Skript gestartet wird, muss es den Verzweigungsnamen aus seinen Aufrufparametern abrufen. Es würde dann den persistierten Zustand für den Zweig erhalten.

Wenn der Status fehlt oder not runningauf gesetzt werden würde running + job ID, führen Sie den Komponententest aus und setzen Sie den Status auf not running(oder löschen Sie ihn).

Wenn der Status lautet running + job ID, bedeutet dies, dass bereits ein anderer Komponententest ausgeführt wird und Sie die entsprechende Job-ID haben. Das Skript kann dann (ordnungsgemäß?) Den bereits ausgeführten Job anhand seiner ID beenden und an seine Stelle treten und den Status auf aktualisieren running + new job ID.

IMHO ist es jedoch nicht ideal, einen laufenden Job zu beenden (der möglicherweise kurz vor dem Abschluss steht) - es lässt Raum für das ständige Beenden von Jobs und das Starten von Nachrichtenjobs, um selbst durch nachfolgende Jobs getötet zu werden - alles ohne tatsächlich einen zu erledigen von ihnen.

Stattdessen würde ich die Logik ändern zu:

• Lassen Sie den laufenden Job in Ruhe und zeichnen Sie stattdessen einfach im dauerhaften Zustand a auf pending job ID(entweder einen eindeutigen Wert, der überschrieben wird, um den zuletzt ausstehenden ausstehenden Job wiederzugeben, oder eine Liste aller ausstehenden Jobs, sortiert nach Übermittlungszeit).
• Wenn der laufende Job abgeschlossen ist, werden die pending job IDWerte überprüft und, falls vorhanden, der neueste (oder der älteste oder sogar eine andere Auswahllogik, wenn eine Liste verwendet wird) gestartet.

Dieser Ansatz vermeidet die Verschwendung von Ressourcen für Komponententests und kann auch für mehr als eine, aber immer noch begrenzte Ressource problemlos angepasst werden.