I am working on a project where i want to copy the compiled file (which compiled through jenkins) from one windows server to another through jenkins. Jenkins is installed on a windows server and after building the code, those compiled file should be copied to another windows server through jenkins. Is there any way to achive it?
Jenkins might be able to do it, via the script steps running the scp command; however, if this is part of a build, I would suggest attaching the file(s) to a project, and distributing them through the maven repository.
Related
My team has code being built and tested in Jenkins and when the build process is done Jenkins produces a SNAPSHOT.jar file. I need to unpacked the snapshot.jar file and send the extracted files and folders to a network drive. What is the best way to do that?
I've tried a few Jenkins plugins, the most recent being artifactDeployer, but when the plugins deploy the artifacts, as a post-build action, they don't unpack the jar files; I would have to execute a windows batch command after they are deployed to unpack them but I cant because the plugin runs as a "post-build action" and the batch commands are done before the post-build actions. Is there a way to deploy the artifacts and unpack them without using a plugin? Or is there a plugin that will do both? What is the best way to achieve this?
The way I accomplished this was by using 7zip in a Windows batch command as a post-step in the jenkins project configuration.
The command is:
`7z x %WORKSPACE%\target\*.jar -oX:\"mapped network drive location" -y`
This extracts the artifacts out of the snapshot.jar file and places those artifacts into the network drive. I needed the files contained in the snapshot.jar to be sent to the network drive when the build completed. I am new to jenkins and the plugins I tried were post-build actions and only copied the snapshot.jar to a given location; they did not extract the artifacts out of the jar file. That is why I chose this route.
I have TeamCity installed on centos. I have only one Linux BuildAgent for now. My build configuration execute a maven script and using ant upload WAR artifact to Windows Server on FTP. After this step i have to execute BAT file on remote Windows Server. I read that i can do this using psexec/RemCom, but i can't understand how i can do this in TeamCity? Build Step or different Build Configuration should contain steps to execute psexec/RemCom or i can insert Build Step into existed Build Configuration?
Single build configuration could potentially consists of multiple build steps. Think of them as a actions you would like to do. So I suppose that right now you have a maven step in your build configuration. I would suggest you to add Command Line step, where you can do what ever you want -- it's like bash/batch script. You can put script contents directly to the build step, or you can write script and execute it.
But as you mentioned that you have CentOS, it could be you have to do extra configuration on the build agent for PsExec to be available.
I am having issues with Jenkins that I am unable to resolve, and all the solutions I've found online I've used in the past, but are not helping.
I am on windows 2008r2, utilizing svn, jenkins version 1.407.
Initially the service failed, and was not resolved with past methods. In the past I have successfully troubleshoot Jenkins by killing hung processes, restoring the war file, ect.
I have attempted a new install with bringing over the files in the jobs folder. The end result was a partially functioning Jenkins would attempt a build it would report no change and not update.
What I'm trying to determine is a list of files/folders beyond the jobs folder that I need to move to the new install. The initial install predates me and was Hudson. The folder has a number of obviously obsolete files and folders (both a jenkins.war and a hudson.war)
Go to Jenkins home folder and collect:
all ./*.xml files in - these are configuration files for plugins and jenkins itself
users/* in case you have security enabled
subversion-credentials/** and secrets/** for any kind of keys provided in jenkins to access svn or other resources
plugins/*.*pi folder for all plugins - you don't need to have the unpacked folders
jobs/*/config.xml - to retrieve all job configurations; jobs/*/nextBuildNumber if you care to continue build numbers
plugins may create additional folders which you may want to use
with that you should recreate Jenkins as it was. Pay especially attention to config.xml file in root folder - this holds main jenkins configuration. If your issue reproduces on new system most likely a plugin is cause for problems - in that case review log files most likely you will find out which plugin causes trouble.
You didn't indicate if you tried new setup with same version of Jenkins or newer one; if you are using newest version it may be that ssh key handling / svn authentication for each job needs to be updated as somewhen in last few months authentication / security handling changed. Best is to look into Jenkins release log.
I'm using Jenkins 1.55x on CentOS installed as RPM; given that it is a webapp I assume Windows 1.4x setup is similar.
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.
i'm new to world of continuous integration and software developement.
I wanted to try hudson so i installed it on my ubuntu machine and created a new job. i pointed it to an open source project's svn (keepassx) just to try.
Hudson downloaded everything from the repository and marked blue for successful build.
aren't i suppose to be able to execute the software now somehow ? i thought once it is built i can run it, but i can't find any executable in the project's home page under hudson user home dir.
thanks.
A Hudson/Jenkins build breaks down into three steps:
update source code in workspace
run build
publish build artifacts
It sounds like you've got step 1 covered.
If the project you linked to has instructions for building (ant, maven, etc.), you can enter these as build steps into the "Build" section of the project configuration.
You can then take the resulting files ("artifacts"--jar, exe, so, bin, whatever) and publish these using the "Post-build Actions", or if necessary you can grab them directly from the workspace filesystem.
Assuming the build artifact was an executable, you could then run it after downloading it from Hudson, or make a build step or post-build action which moved it into the appropriate location and ran it.
It helps to run the build locally before trying to get Hudson to handle it--then you know what the build steps are, and what the final build artifacts are.
How would jenkins/hudson know how to 'execute' some arbitrary package that you told it to download and build? It's up to you to write a program or script to run what you want to run, and then make a downstream job (for example) to do so.