Ich entwickle Plugins für ein Hauptsystem (Moodle), daher ist die kontinuierliche Integration für mich hilfreich.

Die Idee ist, Moodle-stabile Versionszweige zu überprüfen, für die ich das Plugin veröffentlichen möchte, um den Test mit diesen Versionen auszuführen.

Da ich jedoch noch nie mit Jenkins oder Continuous Integration gearbeitet habe, ist mir nicht klar, wann der beste Zeitpunkt wäre, um den Build auszulösen, mit dem die Tests ausgeführt werden. Dies sind die Build-Trigger, die Jenkins anbietet:

  • Trigger-Builds aus der Ferne (z. B. aus Skripten)
  • Erstellen, nachdem andere Projekte erstellt wurden
  • Bauen Sie regelmäßig (cron-like; ich denke nicht, dass es geeignet wäre)
  • Erstellen, wenn eine Änderung an GitHub gesendet wird (könnte sein)
  • Poll SCM (kann keinen Unterschied zum periodischen Build erkennen)

Abgesehen von diesen haben wir die Git-Hooks, die ich auf den ersten Blick interessanter finde als oben.

  • Pre / Post Commit
  • Pre / Post Merge (kann nützlich sein, um Builds nur für bestimmte Zweige auszulösen)
  • Pre / Post Push

Hinweis: Das Git-Plugin für Jenkins schlägt beim Abrufen des Moodle-Repos immer fehl. Es scheint, weil es ziemlich lang ist (ich weiß nicht, ob das Git-Plugin für diesen Ansatz notwendig / wichtig ist).

0
Julen 29 Dez. 2015 im 18:16

2 Antworten

Beste Antwort

Nach meiner Erfahrung ist es am besten, den "Build" auszulösen, wenn ein Commit in das Repository verschoben wird. Ich denke, darum geht es bei "kontinuierlicher Integration".

Vor kurzem hat Mark Nielsen ein Tool entwickelt, mit dessen Hilfe die Tests für Moodle-Plugins in das Travis CI-Tool integriert werden können (http: // travis-ci) .org /).

"Das Tool bietet eine Vorlage der Travis-Konfigurationsdatei - perfekt dokumentiert - sowie hervorragende Nutzungsinformationen." (https://moodle.org/mod/forum/discuss.php?d=) 323384).

Mit dem Tool können Sie verschiedene Tests ausführen, z. B. PHP und JS Lint, Moodles eigenen Code-Style-Checker sowie PHPUNIT- und Behat-Tests. Es testet auch mit mehreren Versionen von PHP mit MySQL- und Postgresql-Datenbanken. Sie können Ihr Plugin auch in verschiedenen Versionen von Moodle testen, aber der Standardzweig ist MOODLE_30_STABLE.

Es ist verfügbar unter https://github.com/moodlerooms/moodle-plugin-ci

1
Daniel Neis Araujo 1 Jän. 2016 im 21:54

Informationen zu Triggern: Es hängt ganz von Ihrer Wahl oder vom Szenario des Projekts ab. Ich werde Ihnen jedoch meine Gedanken basierend auf meinen Erfahrungen mit Jenkins mitteilen.

Trigger-Builds aus der Ferne (z. B. aus Skripten)

Es ist mühsam, den Build immer manuell auszulösen

Erstellen, nachdem andere Projekte erstellt wurden

Ich musste es nie benutzen. Vielleicht kann es in einem ganz bestimmten Szenario verwendet werden (z. B.: Wenn ein Projekt von einem anderen abhängt oder wenn das Projekt zu groß ist und Sie es vielleicht alleine ausführen möchten)

Bauen Sie regelmäßig (cron-like; ich denke nicht, dass es geeignet wäre)

Wird regelmäßig erstellt, Ereignis, wenn es keine Änderung am Code gibt. Wenn der E-Mail-Trigger aktiviert ist, werden Sie mit E-Mails gestört. Am schlimmsten ist es, wenn andere Personen auf dem mailing list enthalten sind.

Erstellen, wenn eine Änderung an GitHub gesendet wird (könnte sein)

Dies ist nützlich, wenn Sie das Projekt alleine entwickeln und das Ergebnis sofort sehen möchten, nachdem Sie Änderungen vorgenommen haben. Diese Option funktioniert jedoch manchmal nicht. Eine Problemumgehung besteht darin, Poll SCM jede Minute auf Änderungen zu überprüfen. (*/1 * * * *)

Poll SCM (kann keinen Unterschied zum periodischen Build erkennen)

Der Hauptunterschied besteht darin, dass Poll SCM zum angegebenen Zeitpunkt nicht erstellt wird, sondern zunächst nach Änderungen sucht. Wenn es überhaupt keine Änderung gibt, wird es nicht erstellt, wohingegen Build periodically ausreicht. Dies ist die Option, die ich meistens benutze. Es ist sehr nützlich. Normalerweise plane ich, nachts mit aktiviertem E-Mail-Trigger zu prüfen und als erstes am Morgen E-Mails auf Build-Fehler zu überprüfen

Über Git-Hooks: Wenn Sie den Build für bestimmte Zweige auslösen möchten, können Sie auswählen, welcher Zweig standardmäßig auf Jenkins erstellt werden soll. Ich hatte auch kein Szenario, in dem ich gezwungen war, Git-Hooks zu verwenden.

1
hrskrs 29 Dez. 2015 im 16:18