I'm using Jenkins to deploy war file into tomcat.Build is success but giving FileNotFound exception.I'm using tomcat7.I found some references in google but didn't get the solution
if you want to copy war from build server to tomacat server ,use robocopy to copy war to tomcat server
robocopy c:abc/abc.war //tomcatserver and path
Most containers have a directory where you can "place" the war, in order to deploy it.
Therefore in Jenkins you can set up Send build artifacts over SSH
More
On configuring the server, you should go in Configure Jenkins -> Configure system -> SSH Servers
Add the server you need to deploy to, username (+password) and Remote directory: /opt/app/tomcat/webapps (or whatever)
More info here - https://wiki.jenkins.io/display/JENKINS/Publish+Over+SSH+Plugin
Related
I have a build configuration that uses the Team City deployer plugin.
I'm using a container deploy to deploy the war file to Tomcat.7.0.63 installed as a service on a Windows Server 2012 R2 box.
The first time I run the the build, the artifact (a war file_ deploys successfully.
The second time, and all subsequent runs, the deploy fails.
The error message:
Build failure message received: org.codehaus.cargo.container.ContainerException: Failed to undeploy
The log file error:
Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Unable to delete
When I go to the webapps folder on the remote server, the war file is deleted, but the expanded folder is only partially deleted. Most files are gone, except for a png file.
I am not able to manually delete the folder because Tomcat still has a lock on it.
If I restart tomcat, I'm then able to run the build successfully (war file deploys).
One thought I had was to restart Tomcat before or after each deploy.
How would I restart Tomcat from TeamCity?
Or perhaps, does anyone have suggestions on how to fix this problem?
You can configure the Tomcat Context using the antiResourceLocking option, as detailed further in the online documentation. This does come with some trade-offs however; definitely worth reading the documentation in full and evaluating if it's a suitable option for your application.
I am on RedHat, using Jboss 5.x and Jenkins. My Jenkins is building the project perfect. I am coping the war file to deploy folder of Jboss with shell script.
When I am running the command on my terminal
scp source/example.war destination/deploy
scp command is able to copy the .war file into deploy folder and through url I am able to access it.
But the when I am writing the same command on jenkins it throws an error.
Permission denied
Build step 'Execute shell' marked build as failure
I guess it is because jenkins try to write the file and it does not have permission.
so how do i do that??
If you are using SCP to copy your file from the Jenkins server to your Jboss server, you should declare the public SSH key of your jenkins user on the Jboss Server.
Please have a look to this answer: add a publickey to server for SCP
I'm trying to setup simple continuous integration system on my local PC. I use gradle as my build system (gradle wrapper option). One of the steps in the build process in to deploy build artifacts to a local repository (located at:
"{user_dir}/.m2/repository)". It works ok when I run it from local PC, but when it runs on Team City CI (version 9) it deploys it to a
"{windows_dir}\System32\config\systemprofile.m2\repository". This is probably some configuration issue but I couldn't manage to solve it. In the build logs I saw that it can't find the local repository in the settings.xml file. I've tried to add it but it didn't help. How can I configure Team City to use local repository folder in user directory?
I found out what was the issue. If you install Team City system services to run under admin account it will always use windows directory. In order to use the User's directory you need to install the services under that user account.
Source: https://confluence.jetbrains.com/display/TCD9/Maven+Server-Side+Settings.
So, I'm writing the build and the deploy scripts. To create the build, I used ant. The continuous build is done with Jenkins.
The build generates 3 different artifacts:
The war file
A zip with layouts
A zip with images
So far, so good, but now I need to write the deploy script, which should:
Deploy the war (artifact 1) to the tomcat running at server 1
Place the artifact 2 at server 1 in a specific directory
Place the artifact 3 at server 2 in a specific directory
So I was talking with my colleague and he said that we should also generate an artifact (maybe deploy.xml) that deploys these artifacts when placed at the correct server.
So there would be another script, that would:
Download the jenkins artifacts
scp to each server and place the deploy.xml there
remotely invoke the deploy.xml
What makes me a little uncomfortable is the act of having the deploy.xml as a build artifact. The motivation behind this would be to be able to make a deploy without needing to have access to the VCS repositories, so a build would be self-contained, ie, any build could go into production only with what was generated by Jenkins.
Where should the deploy scripts be placed? Should they be only at the VCS or should they be build artifacts too?
Please provide if any sample deploy scripts
I wrote my own deployment framework, consisting of different shell, batch, python, and .... scripts. It neatly separates environment information from application information and allows me to quickly update deployment information and add new apps or environment. However, the orchestration of the different parts is done by Jenkins. When just copying files to a Windows server, my Jenkins master (running on Windows) just copies the files to a network share that exposes the target directory. Services I can restart remotly using sc.exe. When crossing the borders to AIX, I use jenkins slaves that are started via ssh on the target system. So distribution is managed by Jenkins. The actual work is done by the scripts.
how can I copy the artifacts from Teamcity to another server?
Thanks
The way I have done this, make things a lot easier.. Setup another configuration that pulls in, via artifact dependencies, all the files you need then run a cmd script to xcopy/copy the files to another drive on the network. You can do this using cmd script, vbs, python, shell etc..
Remember, you only need to refer to directories as if they were local as you would have your script in the same working directory
i.e cmd script :: xcopy .\"my build artifact(s)" \path\to\drive\on\my\network\"my build artifacts"
It doesn't get easier than that.
Naturally, if your artifacts are huge, then you may want to consider your more complicated option. However, TeamCity currently have a ticket pending, which you can vote on, that allows you to run multiple runners in one configuration - so you could just add your cmd script to the same configuration to save the copy time; please vote if can spare a minute:
http://youtrack.jetbrains.net/issue/TW-3660
There is a Deployer plugin, that supports deploy by fileshare/SMB, FTP, SSH and other means. The usage is basically the same as the Artifact paths.
We have used just samba, so you must enter:
target Host path: //server/drive/myfolder
Username: mydomain\myusername - in our case we had to write domain
here too
Password: ****
Domain: mydomain
and in path just select the files as in artifacts:
product/* => product.zip
and it will create file //server/drive/myfolder/product.zip
You can do it from your build script or externally.
If you are looking to get artifacts copied from a remote build agent to the primary TeamCity server, you may want to look into configuring Build Artifacts under the General Settings.
According to TeamCity's wiki entry on BuildArtifacts (http://confluence.jetbrains.com/display/TCD7/Build+Artifact) "Upon build finish, TeamCity searches for artifacts in the build's checkout directory according to the specified artifact patterns. Matching files are then uploaded ("published") to the TeamCity server, where they become available for download through the web UI or can be used in other builds using artifact dependencies."