Demo eurer Buildsysteme
Demo eurer Buildsysteme
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
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
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
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
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.
Bitte macht euch vorher Gedanken, was ihr zeigen wollt und lasst es nicht völlig ungeplant laufen.
Danke.
Re: Demo eurer Buildsysteme
Ist die Vorstellung auch offen für nicht Projektteilnehmer?
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT d- s:+ a-- C++++ UL++++$ P+>+++ L++ E--- W+++$ N+ o+ K? w O M V- PS+ PE++ Y+ PGP- t--- 5--- X-- R tv b DI++ D+ G e h r y?+
------END GEEK CODE BLOCK------
Version: 3.1
GIT d- s:+ a-- C++++ UL++++$ P+>+++ L++ E--- W+++$ N+ o+ K? w O M V- PS+ PE++ Y+ PGP- t--- 5--- X-- R tv b DI++ D+ G e h r y?+
------END GEEK CODE BLOCK------
Re: Demo eurer Buildsysteme
von mir aus 

- MisterD123
- Geek
- Beiträge: 811
- Registriert: 31. Okt 2006 20:04
- Wohnort: Weiterstadt
Re: Demo eurer Buildsysteme
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.
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
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
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!
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
In welchem Raum findet das Ganze denn statt?
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT d- s:+ a-- C++++ UL++++$ P+>+++ L++ E--- W+++$ N+ o+ K? w O M V- PS+ PE++ Y+ PGP- t--- 5--- X-- R tv b DI++ D+ G e h r y?+
------END GEEK CODE BLOCK------
Version: 3.1
GIT d- s:+ a-- C++++ UL++++$ P+>+++ L++ E--- W+++$ N+ o+ K? w O M V- PS+ PE++ Y+ PGP- t--- 5--- X-- R tv b DI++ D+ G e h r y?+
------END GEEK CODE BLOCK------
Re: Demo eurer Buildsysteme
Kaffeeküche. Das müsste A220 sein.
Re: Demo eurer Buildsysteme
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):
Er ist auf dem Server mit mercurial und hudson in der .hg/hgrc des Repositories eingetragen mit
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
Code: Alles auswählen
[hooks]
changegroup = /path/to/script.sh
Re: Demo eurer Buildsysteme
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
// 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
Tutor in SE: Design (& Construction) SS 2011
Re: Demo eurer Buildsysteme
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
Thx. Marcel
Re: Demo eurer Buildsysteme
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.
Das Modul wird über ein einfaches Maven Assembly zu einem ZIP-Archiv gepackt:
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):
Zuletzt wird, wieder mit Maven-Assembly, ein ZIP-Installer für die Anwendung gebaut, der das JRE-Modul als Dependency benutzt:
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
Zunächst haben wir ein Maven-Modul für die JRE.
Code: Alles auswählen
<groupId>de.lda.labconn2</groupId>
<artifactId>JREWin32</artifactId>
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>
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>
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>
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