Warum Jenkins 1.598 und Tomcat 8 automatische Bereitstellung nicht funktioniert

Question

Ich habe Jenkins 1.598. Ich installiere Auto Deployment Plugin in Jenkins (Aber es ist nicht für Tomcat 8, es gibt noch kein Update).

Alles hat gut funktioniert! Nachdem der Build abgeschlossen ist, beginnt er mit der erneuten Implementierung. Aber manchmal habe ich solche Fehler, und ich verstehe nicht, wann und warum es passiert. Wenn ich Tomcat neu starte, geht alles wieder gut!

Deploying C:\jenkins\test\target\tr-gui.war to container Tomcat 7.x Remote 
     Redeploying [C:\jenkins\test\target\tr-gui.war] 
     Undeploying [C:\jenkins\test\target\tr-gui.war] 
    ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception 
    org.codehaus.cargo.container.ContainerException: Failed to undeploy [C:\jenkins\test\target\tr-gui.war] 
     at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:140) 
     at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:178) 
     at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73) 
     at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116) 
     at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103) 
     at hudson.FilePath.act(FilePath.java:981) 
     at hudson.FilePath.act(FilePath.java:959) 
     at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103) 
     at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61) 
     at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45) 
     at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) 
     at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) 
     at hudson.model.Build$BuildExecution.post2(Build.java:183) 
     at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) 
     at hudson.model.Run.execute(Run.java:1784) 
     at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 
     at hudson.model.ResourceController.execute(ResourceController.java:89) 
     at hudson.model.Executor.run(Executor.java:240) 
    Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Unable to delete [C:\servers\tomcat 8\webapps\test]. The continued presence of this file may cause problems. 

     at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:566) 
     at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:480) 
     at org.codehaus.cargo.container.tomcat.internal.TomcatManager.undeploy(TomcatManager.java:420) 
     at org.codehaus.cargo.container.tomcat.Tomcat7xRemoteDeployer.performUndeploy(Tomcat7xRemoteDeployer.java:62) 
     at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:130) 
     ... 17 more 
    org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Unable to delete [C:\servers\tomcat 8\webapps\tr-gui]. The continued presence of this file may cause problems. 

     at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:566) 
     at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:480) 
     at org.codehaus.cargo.container.tomcat.internal.TomcatManager.undeploy(TomcatManager.java:420) 
     at org.codehaus.cargo.container.tomcat.Tomcat7xRemoteDeployer.performUndeploy(Tomcat7xRemoteDeployer.java:62) 
     at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.undeploy(AbstractTomcatManagerDeployer.java:130) 
     at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:178) 
     at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:73) 
     at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:116) 
     at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:103) 
     at hudson.FilePath.act(FilePath.java:981) 
     at hudson.FilePath.act(FilePath.java:959) 
     at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:103) 
     at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:61) 
     at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45) 
     at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) 
     at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) 
     at hudson.model.Build$BuildExecution.post2(Build.java:183) 
     at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) 
     at hudson.model.Run.execute(Run.java:1784) 
     at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 
     at hudson.model 

.ResourceController.execute(ResourceController.java:89) 
    at hudson.model.Executor.run(Executor.java:240) 
Sending e-mails to: test@mytest.com 
Finished: FAILURE 

Answer 1

Ich denke, dass zu der Zeit Ihre Test-und Tr-GUI-Anwendungen nicht ordnungsgemäß geschlossen wurden.

Hier ist ein alter Kommentar von Matt Mello (von this bug report):

ich hatte das gleiche Problem.

Es stellt sich heraus, dass wir eine log4j Appender Setup in unserer App hatte in eine HTML-Datei anhängen in unserem Webapp das Verzeichnis, und offenbar würde LOG4J die Datei nicht freigeben, bis wir den Appen ordnungsgemäß herunterfahren. Herunterfahren der App war nicht genug. Dies ist möglicherweise auf die Tatsache zurückzuführen, dass log4j selbst von tomcat statt von der App geladen wird? Nicht sicher.

Wie auch immer, ich habe Code in der Servlet-Methode destroy hinzugefügt, um die Appender zu bereinigen und dies stellte sicher, dass die Datei geschlossen wurde, so dass Tomcat das Verzeichnis löschen konnte.

[Lassen Sie mich nicht einmal über die Sicherheitsprobleme, die mit dem, was wir tun, loslegen. Das ist ein anderes Thema.]

Beachten Sie, dass velocity möglicherweise auch einige Protokolle in das Verzeichnis Ihrer Webanwendung schreibt. Ich glaube, ich habe das schon früher gesehen.