Hudson auf Glassfish -> "stale files"

Hallo Forum,

ich habe gerade ein Problem mit meinem Hudson (3.0.1). Der Build eines Programms soll automatisch auf unseren Entwicklungsserver (Glassfish 3.1 auf Windows 2008 R2) deployed werden. Wenn die Anwendung aber vorher schon existiert hat, schlägt dieser Vorgang fehl, da der Server wohl Probleme hat, alte Dateien zu löschen. Im “Application” Verzeichnis liegt dann nur noch die Datei .glassfishStale mit folgendem Inhalt:


Application-name-1.0_war/
Application-name-1.0_war/WEB-INF/
Application-name-1.0_war/WEB-INF/lib/
Application-name-1.0_war/WEB-INF/lib/primefaces-3.4.jar
Application-name-1.0_war/WEB-INF/lib/prettyfaces-jsf2-3.3.3.jar
Application-name-1.0_war/WEB-INF/lib/delta-1.0.10.jar

Gibt es da irgendwelche Möglichkeiten das zu umgehen? Hatte das Problem vielleicht sogar schon mal jemand? Die einzige Lösung die ich bisher gefunden habe war “Betriebssystem gewechselt”, das steht aber nicht zur Debatte.
Deployment über das Web-Interface funktioniert tadellos.

Gruß,
Tim

Edit: Natürlich liegen da auch noch die in der Datei angegebenen Datei herum, manuelles Löschen ist nicht möglich, da sie sich irgendwoher im Zugriff befinden.

Windows als CI Master Server ist IMHO sowieso nur 2. Wahl… aber wozu automatisch und vor allem wie deployen?
Puppet Manifeste/Chef Skripte sehe ich ja noch ein, aber ich denke dass ist hier gar nicht der Fall, ist ja nur ein Windows System.

Hudson/Jenkins sind alles andere als sauber geschrieben, vermute dass das noch locks auf Dateien gibt die das loeschen und Windows verhindern.
Wuerde mal vermtuen dass das wirklich nur mit einem anderen OS oder anderen CI Server geht.

Es ist eine recht kleine Anwendung zur Überstundenverwaltung die auch ziemlich wenige Commits bekommt. Ich habe ein „Deployment Plugin“ im Hudson installiert und checke zyklisch gegen das SCM, nennen wir es mal eine Art „Nightly Build“. Auf dem Testsystem sollte immer eine aktuelle Version zu finden sein.

Hudson/Jenkins sind alles andere als sauber geschrieben, vermute dass das noch locks auf Dateien gibt die das loeschen und Windows verhindern.
Wuerde mal vermtuen dass das wirklich nur mit einem anderen OS oder anderen CI Server geht.

Das mit der Code-Qualität habe ich so auch schon mehrfach gehört, bisher war ich aber für unsere Zwecke noch recht zufrieden damit. Naja, ist ja jetzt nichts kriegsentscheidendes, wäre eher Kategorie „nice to have“ gewesen. Es lohnt auf jeden Fall nicht die Zeit, die ich damit verbraten würde da nach einer Lösung zu suchen.

Danke für die Antwort!

Naja, Linux macht das nix aus wenn geoeffnete Dateien geloescht werden, denke das liegt der Hase im Pfeffer, von daher stimme ich dir zu, der Aufwand waere zu gross.

Ich weiß, deshalb sind Linux Server bei mir privat auch erste Wahl für so etwas. Mein Arbeitgeber hat aber eine Windows-Only Landschaft, die steht auch nicht zur Diskussion.

Passiert denn der Undeploy? Mit Websphere kenne ich mich nicht aus aber bei JBoss würde automatisch ein undeploy angestossen werden wenn du neue Daten reinkipst.

Probier einfach mal aus vor dem Hudson-Deploy die entsprechende Applikation zu undeployen. Wenn das funktioniert kannst du vor dem deploy noch ein skript ausführt das den undeploy durchführt.

So halb. Wenn die Meldung kommt, dass der Undeploy erfolgreich war, sind die Files noch für ein paar Sekunden da. Dann bringt mir dann auch die eigentlich gute Idee mit dem Undeploy-Skript leider nichts, auf jeden Fall nicht zuverlässig.

Falls die Files beim Undeploy verlässlich verschwinden würde ich in deinem Fall ein simples Programm schreiben das blockiert solange der Ordner nicht weg/leer ist (sollte ja mit Powershell unter Windows sehr leicht möglich sein). Das rufst du am Ende deines Undeploy-Skripts auf und gut ist. Der Hudson wartet bis das ganze Skript zu Ende gelaufen ist und startet erst wenn der Ordner frei ist.

Ist zwar ein ziemlicher Hack, aber so etwas ähnliches musste ich auch schon mal machen weil Selenium Grid sehr herum gezickt hat. Jetzt startet das Skript die Services neu vor jedem Testlauf…

Nicht schön, funktioniert aber.