Demo eurer Buildsysteme

[marcel_b]

Hi,

wie kurz angesprochen: Bitte nennt uns drei mögliche Termine für die erste oder zweite Augustwoche.
Ziel: wir würden gerne eine Demo eures Buildsystems bekommen.

Viele Grüße
Marcel

[marcel_b]

Zwei Termine stehen:

Team LIKED IT:12.08 10 Uhr
Team R.E.D.: 12.08. 11 Uhr

Wenn sich das letzte Team um diese Termine drum herum organisieren könnten (±1h) wäre das klasse.

Danke und viele Grüße
Marcel

[marcel_b]

BTW: Die Buildsystem Demo ist grundsätzlich offen für alle Teams zu schauen.

Bitte macht euch vorher Gedanken, was ihr zeigen wollt und lasst es nicht völlig ungeplant laufen.
Danke.

[kahler]

Ist die Vorstellung auch offen für nicht Projektteilnehmer?

[marcel_b]

von mir aus

[MisterD123]

wenn du dich traust *g*

[Pan]

Hallo,
gibt es für diese "Demo unseres Buildsystems" eigentlich eine Note, oder wollt ihr euch nur einen interessierten Überblick verschaffen?

Falls ihr das tatsächlich benoten wollt, brauchen wir bitte im Voraus die Bewertungskriterien, denn es ist uns nicht klar, welche Bedeutung die Bewertung eines Systems hat, das sich für unsere Zwecke bewährt hat.

[marcel_b]

Bewertet wird *insgesamt* wie ihr insgesamt eure Qualität sicher stellt. Das Buildsystem ist eine Komponenten davon, die im QS Dokument beschrieben wird. Das QS Dokument bildet eine Bewertungsgrundlage. Die Demo zeigt, was und wie ihr es tatsächlich umsetzt.

[marcel_b]

Hi, die Termine liegen jetzt im Stundentakt:

9-10
10-11
11-12

Wer also von externe kommen möchte: ab 9. Kaffee muss jeder leider selbst mitbringen.
Bis Freitag dann!

[kahler]

In welchem Raum findet das Ganze denn statt?

[marcel_b]

Kaffeeküche. Das müsste A220 sein.

[tgp]

Wir hatten ja heute morgen gezeigt, dass unser hudson nur dann anspringt, wenn auf dem default-Branch was geändert wurde. Zusätzlich wird noch überprüft, ob die Änderung außerhalb des Dokumenten-Ordners ("Deliverables") passiert, weil ja z.B. ein QS-Doku-Update keinen Build triggern muss.

Für den, den dieses Ausschließen näher interessiert, hier unser Mercurial-Hook als Bash-Script (/home/hg/data ist das Repository):

Code: Alles auswählen

#!/bin/bash

# for every mercurial changeset up to the tip
for node in $(hg -R /home/hg/data log -r $HG_NODE:tip --template '{node}\n') ; do
   # if the changeset is on the default branch 
   if [[ $(hg -R /home/hg/data id --branch -r $node) == "default" ]] ; then
      # if the changeset description does not begin with "[maven-release-plugin]" (would cause endless re-build)
      if [[ $(hg -R /home/hg/data log -r $node --template '{desc}\n') != \[maven-release-plugin\]* ]] ; then
         # look in every changed file
         for file in $(hg -R /home/hg/data log -r $node --template '{files} {file_mods}\n') ; do
            # if there is one file not in the "Deliverables" folder
            if [[ $file != Deliverables/* ]] ; then
               # trigger the hudson build by making a HTTPS GET to the job build URL, 
               # discarding wget output and ignoring the certificate for HTTPS
               wget -q -O /dev/null --no-check-certificate https://localhost/hudson/job/SE-Projekt/build
               exit 0
            fi
         done
      fi
   fi
done

Er ist auf dem Server mit mercurial und hudson in der .hg/hgrc des Repositories eingetragen mit

Code: Alles auswählen

[hooks]
changegroup = /path/to/script.sh

[kde]

Hier eine kurze Anleitung, wie man Firefox mit Hilfe von Xvfb headless starten lassen kann:
// Xvfb auf DISPLAY 99 im Hintergrund starten (oder in die /etc/init.d hängen)
Xvfb :99 -screen 0 1024x768x24 &
// aktuelles Display vor Programmstarts immer explizit auf 99 setzen
export DISPLAY=:99
// firefox starten
firefox

[marcel_b]

Habt ihr Anleitungen aus dem Web parat, die erklären, wie ihr eure Win VM + JRE Installer zusammen gebaut habt? Ich denke, dass könnte für das erste Team ganz interessant sein.

Thx. Marcel

[spark]

Eine direkte Anleitung aus dem Web habe ich dafür nicht. Das habe ich selbst gebastelt... ich kann aber gerne den groben Ablauf und ein Paar POM-Auszüge posten:

Zunächst haben wir ein Maven-Modul für die JRE.

Code: Alles auswählen

<groupId>de.lda.labconn2</groupId>
<artifactId>JREWin32</artifactId>

Das Modul wird über ein einfaches Maven Assembly zu einem ZIP-Archiv gepackt:

Code: Alles auswählen

<assembly ...>
	...
	<formats>
		<format>zip</format>
	</formats>
	<fileSets>
		<fileSet>
			<directory>${project.basedir}/src/main/resources</directory>
			<outputDirectory>/</outputDirectory>
			<includes>
				<include>**/*</include>
			</includes>
		</fileSet>
	</fileSets>
</assembly>

Das Modul, das wir mit gebundelter JRE ausliefern wollen, erzeugt mit launch4j einen EXE-Starter, dem man den Pfad zu einer JRE/JVM konfigurieren kann (Das ist dann der erste Pfad an dem gesucht wird. Findet sich da nichts, wird weiter nach systemweiten Java-Installationen gesucht):

Code: Alles auswählen

<plugin>
	<groupId>org.bluestemsoftware.open.maven.plugin</groupId>
	<artifactId>launch4j-plugin</artifactId>
	...
	<executions>
		<execution>
		...
			<configuration>
				<jre>
					<!-- release variant has bundled jre -->
					<path>jre/</path>
				</jre>
				...
			</configuration>
		</execution>
	</executions>
</plugin>

Zuletzt wird, wieder mit Maven-Assembly, ein ZIP-Installer für die Anwendung gebaut, der das JRE-Modul als Dependency benutzt:

Code: Alles auswählen

<assembly...>
	...
	<fileSets>
		...
		<fileSet>
			<directory>${project.build.directory}</directory>
			<outputDirectory>/</outputDirectory>
			<includes>
				<include>*.exe</include>
			</includes>
		</fileSet>
	</fileSets>
	<dependencySets>
		...
		<dependencySet>
			<scope>provided</scope>
			<useProjectArtifact>false</useProjectArtifact>
			<outputDirectory>/</outputDirectory>
			<includes>
				<include>de.lda.labconn2:JREWin32</include>
			</includes>
			<unpack>true</unpack>
			<unpackOptions>
				<excludes>
					<exclude>**/META-INF/**</exclude>
				</excludes>
			</unpackOptions>
		</dependencySet>
	</dependencySets>
</assembly>

Und schon haben wir ein Artefakt mit einem jre-Ordner auf der höchsten Ebene, auf das die Starter-EXE verweist. Das ganze kann man noch schön mit eigenen Fehlermeldungen (zB JRE nicht gefunden) etc. ausgestalten.

Wir haben die Lösung über eine Maven-Modul gewählt, damit die JRE nicht in unser SCM muss und wir trotzdem auf allen Maschinen bauen können. Das JRE-Modul liegt übrigens in unserem Maven-Repository auf der RBG-VM und wird beim Bauen automatisch geladen.

Hoffe das hilft weiter!
Gruß,
Sven