Currently in german only.

Nicht mehr alles aktuell.

Was ist zu tun, wenn Build fehlgeschlagen?

...

• Odysseus Hourly Build
  Dieser Job checkt nur jede Stunde, ob Odysseus gebaut werden kann oder ob es Probleme gibt. Dabei werden im Prinzip alle Features und Bundles wie in Eclipse mit "Building Workspace" compiliert und daraus eine Update Site erzeugt. Diese Update Site ist unter http://odysseus.informatik.uni-oldenburg.de/hourlyupdate/ zu finden und kann z.B. für kurzfristige Updates genutzt werden.

...

Aufbau des Produkts: Platform + Hauptfeature

...

• "Build Odysseus Server" nimmt  das Product mit der ID "de.uniol.inf.is.odysseus.product.server - das ist die Datei "Odysseus Product Platform Server.product" als Basis-Platform
  
  • de.uniol.inf.is.odysseus.product.server beinhaltet das Feature de.uniol.inf.is.odysseus.product.server.platform.feature
  • de.uniol.inf.is.odysseus.product.server.platform.feature definiert die Platform für das Server-Produkt durch die Bundles: Equinox/Eclipse + de.uniol.inf.is.odysseus.product.server.starter
  • de.uniol.inf.is.odysseus.product.server.starter startet alle installierten Bundles - also auch Odysseus, dass jedoch durch das Hauptfeature installiert wird.
  • Zu dem Product-Definition installiert "Build Odysseus Server" zusätzlich das Feature de.uniol.inf.is.odysseus.product.server.feature
  • de.uniol.inf.is.odysseus.product.server.feature bündelt alle notwendigen Features von Odysseus (core, planmgt, relational...)
    
    
• "Build Odysseus Studio" nimmt  das Product mit der ID "de.uniol.inf.is.odysseus.product.studio - das ist die Datei "Odysseus Product Platform Studio.product" als Basis-Platform
  
  • de.uniol.inf.is.odysseus.product.studio beinhaltet das Feature de.uniol.inf.is.odysseus.product.studio.platform.feature
  • de.uniol.inf.is.odysseus.product.studio.platform.feature definiert die Platform für das Studio-Produkt durch die Bundles: Equinox/Eclipse + de.uniol.inf.is.odysseus.product.studio.starter
  • de.uniol.inf.is.odysseus.product.studio.starter startet die GUI (also auch das Splash + Login etc.) und alle installierten Bundles - also auch den Client-Teil von Odysseus, dass jedoch durch das Hauptfeature installiert wird.
  • Zu dem Product-Definition installiert "Build Odysseus Studio" zusätzlich das Feature de.uniol.inf.is.odysseus.studio.feature
  • de.uniol.inf.is.odysseus.studio.feature bündelt alle notwendigen Client(!!)-Features von Odysseus (Odysseus-RCP, GEF etc.)
    
    
• "Build Odysseus Server + Studio" nimmt  das Product mit der ID "de.uniol.inf.is.odysseus.product.studio - das ist die Datei "Odysseus Product Platform Studio.product" als Basis-Platform
  
  • de.uniol.inf.is.odysseus.product.studio beinhaltet das Feature de.uniol.inf.is.odysseus.product.studio.platform.feature
  • de.uniol.inf.is.odysseus.product.studio.platform.feature definiert die Platform für das Studio-Produkt durch die Bundles: Equinox/Eclipse + de.uniol.inf.is.odysseus.product.studio.starter
  • de.uniol.inf.is.odysseus.product.studio.starter startet alle installierten Bundles - also auch Odysseus, dass jedoch durch das Hauptfeature installiert wird.
  • Zu dem Product-Definition installiert "Build Odysseus Server + Studio" zusätzlich das Feature de.uniol.inf.is.odysseus.product.serverandstdio.feature
  • de.uniol.inf.is.odysseus.product.serverandstudio.feature bündelt alle notwendigen Features von Odysseus (core, planmgt, relational...) und zusätzlich das Feature de.uniol.inf.is.odysseus.studio.feature (s.o) für die GUI (Odysseus RCP, GEF etc.)

...

Man kann hierbei erkennen, dass Studio und Server+Studio sich nur dadruch unterscheiden, dass jeweils ein anderes Hauptfeature hinzu installiert wird.

Da das eigentliche Odysseus über das Hauptfeature "nachinstalliert" wird, startet das Product "Odysseus Product Platform Server.product" bzw. "Odysseus Product Platform Studio.product" nicht Odysseus - es kennt Odysseus nicht einmal und darf es auch nicht kennen!!! Das heißt, dass man zum Starten per Hand (z.B. aus Eclipse heraus zum Entwickeln) ein eigenes Produkt (a la das alte Memory Store Product) brauch, das sowohl das Platform-Feature als auch das Hauptfeature beinhaltet!!

Kontrolle des Build-Prozesses

...

• "Fetsch and Build Target Platform" muss vorher einmal gemacht worden sein. Da dies der Fall ist und sich selten etwas ändert, wird dieser Schritt nur manuell ausgeführt (siehe unten). Der automatische Build geht dann wie folgt los:
• Als erstes wird ein revert und svn update in den Workspace gemacht: /opt/jenkins/workspace/odysseus
• Dann werden die Ausgabe-Verzeichnisse unter /opt/jenkins/output/nightly gelöscht
• Dann wird die de.uniol.inf.is.odysseus.creatermap/src/de/uniol/inf/is/odysseus/creatermap/CreateRMap.java compiliert und ausgeführt. Diese erzeugt eine lokale - neue site.rmap. Diese Datei sagt Buckminster im Prinzip welche Bundles und Features verwendet werden sollen und wo sie sich im Dateiverzeichnis (im Workspace) befinden. Die Java-Datei CreateRMap ist daher nur ein Programm, welches eine site.rmap für alle Bundles und Features erzeugt, die sich unter trunk befinden (so dass die site.rmap nicht immer per Hand angepasst werden muss). Wichtig hierbei ist wie oft erwähnt, dass die Bundles, Features und Produkte eindeutige (unique) IDs haben.
• Anschließend wird Buckminster (also der headless RCP/Eclipse-Build ausgelöst). Dieser verwendet die Target-Platform, die mit dem Build-Schritt "Fetch and Build Target Platform" erzeugt wurde und zusätzlich die site.rmap. Das heißt, dass das headless-Build im Prinzip ein temporäres Sammlung von Bundles erzeugt, in denen zum einen die Bundles sind, die über die Target-Platform heruntergeladen wurden und zum anderen auch alle Bundles sind, die in der site.rmap definiert sind (welches alles in trunk sind, da diese ja dynamisch generiert wird). Beides (Target-Platform und site.rmap) wird also als erstes importiert.
• Dann wird der build ausgeführt, indem die Features gebaut werden, die in der feature.xml in de.uniol.inf.is.odysseus.update.p2 definiert wurden. Hierbei erkennt man, dass natürlich dann auch alle notwendigen Bundles eines dort definierten features entweder Teil der Target-Platform sein müssen oder selbst als Bundle im trunk vorliegen müssen.
• Das Ergebnis wird nach /opt/jenkins/output/nightly/result geschrieben. Die Update-Site wird dann unter /opt/jenkins/output/nightly/update erzeugt. Dies ist auch exakt das Verzeichnis, welches über einen dynamischen Link von http://odysseus.informatik.uni-oldenburg.de/update/ aufgerufen wird.
• Dann werden die Produkte gebaut. Dazu nimmt Buckminster (welches ja von Jenkins ausgeführt wird) die buckminster.cspex  und ruft die dort angegebenen Actions (je Produkt zwei actions: einmal das Bauen des Produktes selbst und einmal das Ergebnis zippen) auf. Diese rufen wiederrum jeweils das ANT-File product.ant auf, welches dann einen headless-build mit Hilfe von Equinox (ruft also im Prinzip eine Jar mit Java auf) ausführt.
• Wenn ein Produkt gebaut wurde, dann wird es nach /opt/jenkins/output/nightly/downloads geschrieben. Jeweils in einen Unterordner, der in der buckminster.cspex mit (action.output) definiert ist. Dieses Verzeichnis ist im Apache (siehe Lampp) als http://odysseus.informatik.uni-oldenburg.de/download/studio/nightlybuild/ eingehängt und somit extern zugreifbar.
• Ist ein Produkt fertig, stößt die Build-Pipeline den nächsten Build für ein anderes Produkt an

Wird "Fetch and Build Target Platform" manuell ausgeführt, dann wird zunächst

• der Ordner "trunk/ci" des SVN ausgecheckt (in den Ordner /var/lib/jenkins/workspace/shared2)
• dann wird die Datei "target-platform.target" aus dem Projekt de.uniol.inf.is.odysseus.updatesite geöffnet. und die Target-Platform wird anhand der Update-Sites, die in target-platform.target definiert sind, heruntergeladen (dazu wird das verzeichnis /var/lib/jenkins/output/temp2 als temporäres Verzeichnis genutzt und das Ergebnis wird nach /var/lib/jenkins/output/result2 geschrieben
• danach wird das Ergebnis (also alle Bundles der Target-Platform, die heruntergeladen wurden) archiviert - das heißt, dass die Target-Platform dann im Prinzip für zukünftige (andere) Builds persistiert wird.
• Anschließend werden die anderen Builds angestoßen (siehe oben)

Additional Build Processes

...

After a successful build, the artifact will remain in the workspace. Marco Grawunder can we copy the artifact somewhere to provide it as a download or pull it to dockerhub?