|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jenkins 1.574 / Tomcat 7.0.55 / JRE 1.7.0_60 / Deployer 1.10
I think this is a more subtle issue may actually be a Cargo issue (haven't checked the bugs there).
I was able to deploy a WAR file with the name appName##NN.war (where NN is constructed from the BUILD_NUMBER) once. I accomplished this by using the following Ant glob pattern for the WAR/EAR file:
*/.war
I left the context path blank, and I made sure to not include a context.xml with a path attribute.
However, the second attempt (the actual parallel deployment) failed with:
ERROR: Publisher hudson.plugins.deploy.DeployPublisher
aborted due to exception
org.codehaus.cargo.container.ContainerException:
Failed to undeploy /home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##14.war
Once I undeployed the application from the remote Tomcat, I could then successfully run another Maven deploy job, which incremented the BUILD_NUMBER.
I can post the entire stack trace if needed.
First of all, the entire point of doing a parallel deploy is to avoid undeploying a live application.
Second of all, the undeploy command needs to be instrumented in order to handle versions (/manager/text/undeploy?context=ConsumeIt&version=14)
While Cargo's performUndeploy for Tomcat7x overrides the stock method, the Javadoc doesn't mention versions.
getPath and getVersion explicitly mention version support.
My initial reaction is that the Tomcat7xRemoteDeployer Cargo class needs to recognize that it's dealing with a versioned WAR file and not attempt to undeploy.
For the undeploy command, there needs to be an optional version component.
It appears that Tomcat8xRemoteDeployer suffers from the same issue.