Changelog Nightly Build

[greiol]

irgendwie scheint das changelog den buildnummern ziemlich hinterher zu hinken, oder übersehe ich etwas?

 

[pfeffer]

welches Changelog?

Vermutlich guckst Du auf dem Nightly Builds-Server?

Dort wird auf der Webseite, die hier verlinkt ist, im Moment nur die Ewe-Version angezeigt. Wir arbeiten aber bereits an der Eve-Version. Dabei werden die SVN-Nummern hochgezöhlt, auch für Ewe, obwohl sich in der Ewe-Version nichts getan hat.

Meinst Du dieses Phänomen?

Gruß,
Pfeffer.

 

[Engywuck]

Sehr seltsames Verhalten dort. Die letzten beiden Revisions, die am EWE-Zweig was gemacht haben, waren 1623, 1597 und 1589. Und das sind nun gerade die Revisions, die NICHT in den Nightly Builds auftauchen. Dagegen tauchen die ganzen andern Builds, die an der EWE-Entwicklung gar nichts verändert haben, fleissig auf... Das sieht ja fast so aus, als ob im Skript, dass die Builds erstellt, ein NOT-Operator zu viel oder zu wenig ist.

Gruß,
E.

 

[König Moderig]

An dem Build-Skript ist gar nix zu viel oder zu wenig ...

 

[König Moderig]

Der Build Service läuft wieder.

Das Problem was da war ist ein Phänomen, das ich bis heute nicht geklärt habe. Übe rNacht kam es dazu, dass der Benutzer, der auf meinem Server die Builds baut, Java nicht mehr ausführen durfte, weil der Kernel den Prozess sofort killt. Ich habe mittlerweile das Homeverzeichnis geleert, alle PAM-Limits ausgeschaltet, Quotas für den Benutzer deaktiviert - er kann Java einfach nicht ausführen ...

Das Script läuft jetzt als anderer Benutzer udn alles klappt.

-nik

 

[Engywuck]

Dieses Problem scheinst Du aber noch nicht angegangen zu sein:

Die letzten beiden Revisions, die am EWE-Zweig was gemacht haben, waren 1623, 1597 und 1589. Und das sind nun gerade die Revisions, die NICHT in den Nightly Builds auftauchen. Dagegen tauchen die ganzen andern Builds, die an der EWE-Entwicklung gar nichts verändert haben, fleissig auf... Das sieht ja fast so aus, als ob im Skript, dass die Builds erstellt, ein NOT-Operator zu viel oder zu wenig ist.

Die genannten Revisions sind zwar auf der Build-Seite jetzt nicht mehr zu sehen, aber ich sehe Build 1628. In diesem Build hat sich auf EWE-Seite nix getan. Bei Build 1627 dagegen hat sich was getan, und dieses Build sehe ich aber nicht.

Noch mal deutlicher: Es sollte nur dann ein Build erstellt werden, wenn sich innerhalb des Zweiges http://195.37.77.137/svnroot/repos/cachewolf/trunk etwas getan hat.

Gruß,
E.

 

[König Moderig]

Hallo,

das Build wird immer erstellt, die Builds die durch den Systemfehler verloren gegangen sind werden nicht nachgebaut. Dabei bleibt es auch.

-nik

 

[pfeffer]

die Windows-Exe gibbet irgendwie nicht:
http://pub.naturalnet.de/~nik/CacheWolf-BE/zcurrent/x86-StaticLinked/CacheWolf.exe --> 404

Ich fänd's auch schön, wenn nicht neu gebaut würde, wenn es nix neues gibt. Das scheint ja auch ganz einfach anhand der svn-changelog für den Zweig zu erkennen zu sein. Kann man da nicht leicht eine Abrafrage an den Beginn des Skripts setzen?

Gruß,
Pfeffer.

 

[König Moderig]

Rein theoretisch sollte "svn update" nichts tun, wenn es in dem Zweig keine Änderungen gab. Und wenn "svn update" nix tut, tut der Rest vom Script auch nix. So war es bisher eigentlich auch immer, deswegen werde ich das erstmal beobachten.

-nik

 

[Engywuck]

Kommt drauf an, was Du mit "nichts tun" meinst. Es werden natürlich keine Sourcecode-Dateien geändert, wenn sich da nichts getan hat, aber die SVN-working-copy aktualisiert sich natürlich auf die letzte Version. Daher darf man wohl nicht nur auf Versionsnummernunterschiede gucken (ich hab das so in Erinnerung von der letzten Lektüre des Skripts...), sondern eher darauf, ob Dateien heruntergeladen wurden.

Gruß,
E.

 

[pfeffer]

also, ich hab ja keine Ahnung von SVN, aber wenn ich das richtig sehe, dann gibt der svn update keine commit-messages aus, wenn in dem Zweig nichts geändert wurde, sondern nur in anderen Zweigen. Das kann man doch recht leicht prüfen, oder?

Vielleicht liege ich auch falsch, aber auf der NB-Ewe-Seite sieht man nur leer commit-messages (meiner Erinnerung nach)

Gruß,

Pfeffer.

 

[König Moderig]

Naja, wir schauen mal ...

 

[Engywuck]

Hatte heute Nacht, als ich vom Klo wieder zurück ins Bett kroch, den rettenden Einfall: Die Überprüfung der Version bleibt wie sie ist. Zusätzlich merkst Du Dir zu jedem aktuellen Build eine Checksumme der erstellen Dateien (da sollte eine der EXEs und die Datendatei reichen). Wenn der neue Build eine andere Checksumme liefert, hat sich was getan - ansonsten nicht.
Dieses Vorgehen verhindert dann auch, dass ein Build veröffentlicht wird, wenn sich eigentlich nur eines der Scripte oder die Dokumentation geändert hat.

Gruß,
E.

 

[MiK]

Also erst bauen und dann sehen, dass es unnötig war?
Dann lieber mit "svn info" arbeiten. Da bekommt man für ein SVN-Verzeichnis die Revision, in der zuletzt etwas darin geändert wurde.

 

[MiK]

Sehe ich das richtig, dass schon mit "svn info" gearbeitet wird? Dann sollte man aber nicht "Revision:" herausparsen, sondern "Letzte geänderte Rev:". Oder besser noch --xml benutzen. Dann ist es nicht sprachabhängig.

 

[Engywuck]

Teilweise hast Du Recht. Die Funktion kannte ich noch gar nicht (arbeite normalerweise mit TortoiseSVN).
Bleibt nur noch die Sache mit den Revisions, bei denen sich nichts am Programmcode oder den Datendateien, sondern nur an den Scripten (und was da noch so liegt) ändert. Und ich fände es schon praktisch, wenn nur noch dann Builds erzeugt (bzw. veröffentlicht) würden, wenn sich für den Anwender wirklich was getan hat.

Gruß, E.

 

[MiK]

Aber welche Dateien willst Du dabei ausschließen? Die Buildscripte können auch die Builds beeinflussen. Und wenn sich an des res_noewe-Dateien etwas ändert, sollte der User die auch updaten.
Außerdem sind binaries oft nicht binär gleich, auch wenn sie aus dem selben Code generiert werden, weil irgendein Builddatum ohne ähnliches drin steckt. Das ist also auch nicht so klar zu erkennen.
Ich würde also sagen: Wenn sich in dem SVN-Zweig etwas ändert sollte es auch neue Builds geben. Dafür sind das eben automatische NBs und keine Releases.

 

[Engywuck]

Wir können uns ja auf folgendes einigen: Wenn die veröffentlichten Dateien binär gleich sind müssen sie nicht veröffentlicht werden.
Und wenn The Hawks mal grad nichts zu tun(*) und Lust hat, seine Build-Skripte etwas zu optimieren, dann kann er - wenn nicht grad was besseres im Fernsehn kommt - diese Änderung einbauen, ohne dass wir davon Nachteile haben.
Oder sind wir jetzt immer noch unterschiedlicher Meinung? ;-)

Gruß, E.

(*) Wobei ich hier noch davon ausgehe, dass er bereits 6 Stunden an der Eve-Umstellung gearbeitet hat und jetzt mal gedankliche Abwechslung braucht.

 

[MiK]

Klar *kann* man das so machen. Nur den großen Vorteil sehe ich nicht. Schadet es denn irgendjemand, wenn er eine Datei mit der gleichen überschreibt?

 

[König Moderig]

Oh ja, wenn ich ausgeschlafen habe nach dem WE mache ich das ....

Aber wie wäre es, das mal zu lassen, weil in absehbarer Zeit fliegt die EWE-Umgebung doch eh weg ?

-nik