Seite 1 von 1

Demo eurer Buildsysteme

Verfasst: 8. Jul 2011 12:14
von 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

Re: Demo eurer Buildsysteme

Verfasst: 11. Jul 2011 11:11
von 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

Re: Demo eurer Buildsysteme

Verfasst: 11. Jul 2011 13:06
von 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.

Re: Demo eurer Buildsysteme

Verfasst: 12. Jul 2011 19:30
von kahler
Ist die Vorstellung auch offen für nicht Projektteilnehmer?

Re: Demo eurer Buildsysteme

Verfasst: 12. Jul 2011 19:33
von marcel_b
von mir aus :)

Re: Demo eurer Buildsysteme

Verfasst: 12. Jul 2011 21:44
von MisterD123
wenn du dich traust *g*

Re: Demo eurer Buildsysteme

Verfasst: 7. Aug 2011 14:13
von 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.

Re: Demo eurer Buildsysteme

Verfasst: 7. Aug 2011 14:18
von 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.

Re: Demo eurer Buildsysteme

Verfasst: 8. Aug 2011 15:57
von 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!

Re: Demo eurer Buildsysteme

Verfasst: 8. Aug 2011 21:22
von kahler
In welchem Raum findet das Ganze denn statt?

Re: Demo eurer Buildsysteme

Verfasst: 8. Aug 2011 21:24
von marcel_b
Kaffeeküche. Das müsste A220 sein.

Re: Demo eurer Buildsysteme

Verfasst: 12. Aug 2011 15:52
von 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

Re: Demo eurer Buildsysteme

Verfasst: 12. Aug 2011 18:43
von 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

Re: Demo eurer Buildsysteme

Verfasst: 12. Aug 2011 18:47
von 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

Re: Demo eurer Buildsysteme

Verfasst: 14. Aug 2011 12:26
von 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