I would like to know, how to copy the "Post Build Activity" setting to all other builds in the same Jenkins server.
Example :
I have 100 or more builds are running in the Jenkins server.
Recently I have installed "Work Space Cleanup" plugin in the Jenkins Server
Now I have to enable/set the "Work Space Cleanup" property which is there in "Post Build Activity" for all 100 builds.
I am looking out for a common place in Jenkins to update the setting which intern updates the same setting for all 100 builds.
Thanks in advance.
Regards,
Bhupal.
Depending on what you require Configuration Slicing plugin has removed the support for the exact plugin you're asking for, but it would probably be possible to make a batch file, python script or something that removes the files wanted and then slice it among the projects.
When you are saying builds, i assume you mean to say projects/jobs. When you create a job, the configuration is stored in config.xml which is present on Jenkins server under the following path:
/path_to_jenkins_setup/jobs/job_name/config.xml
Just open the file and find the relevant portion that you need to replicate in other jobs. Create a script to copy the relevant portion to all jobs' config.xml.
Don't forget to restart Jenkins after making the changes. Alternatively, you can reload your changes by clicking on Reload Configuration from Disk which is present in Jenkins > Manage Jenkins section.
Related
I have a Java project that is running as a job on a Jenkins server. The project is generating a file that is being stored locally on the server in the respective project folder. Currently, to get hold of this file, I am logging into the Jenkins server and get it manually. I would like to make this file available for download directly through the Jenkins job somehow. Not sure if there is a way to do that though. Is there a plug in that might add this functionality or is there any other way to achieve that?
Archive the file. For a freestyle job, that would be a "Post Build Step". For a pipeline job, use archiveArtifacts.
You definitely don't want to rely it on it being in a workspace on the Jenkins agent machine somewhere. The workspace directories can move and change, or be removed.
I have a working Jenkins TFS setup, but can't figure out how to stop the Jenkins TFS plugin from deleting the whole workspace and downloading it again each time.
I just want it to do the equivalent of "Get Latest" and not delete any files that are up to date.
Here is the message I'm getting in the console when this happens:
Deleting workspace as the configuration has changed since a build was performed on this computer.
I can't figure out what is causing this or how to disable this behavior.
This doesn't always happen when I build the project, so something is causing this to happen.
It can happen even if I don't change any configuration stuff in Jenkins.
Option to "Delete workspace before build starts" option is off.
I have found the message in the Java source for the TFS plugin here, but
don't understand what is causing it: Java TFS Plugin in GitHub
Environment:
Jenkins v2.60.3
TFS plugin 5.121.0
Windows 10 64-bit
Java 1.8
Console log when this happens:
Building on master in workspace D:\Jenkins\workspace\XXX
Deleting workspace as the configuration has changed since a build was performed on this computer.
Downloading list of workspaces from https://tfs.company.com/tfs/Projects...
Deleting workspaces named 'MASTER-XXX' from computer 'ALAN-XXX'...
Deleted 1 workspace(s) named 'MASTER-XXX'.
Querying for remote changeset at '$/XXX' as of 'D2017-08-29T09:46:26Z'...****
In your Jenkins Project configure Page ,there is an option for deleting workspace before build starts in Build Environment section. Double check if you are checking this option or not.
The plugin checks the latest build configuration and compare it with the current job. If there is any difference/change exist, you will see that message. The configuration it checks is the settings in "Source Code Management". Since you mentioned that it also occurs when you didn't do any change, I suspect that it may caused by some variables you used in "Workspace name" changed. You can also check and compare the "build.xml" for the two builds in Jenkins Jobs folder to see what change cause the issue you meet.
This is reproducible 100%.
We are working on different branches of the release, but each branch should run the same jobs, with some minor change. So ideally I want to copy all the jobs from one working branch to a new branch.
I select a New item -> folder and select copy from another folder.
The new folder contains the all the jobs from source folder, but all the job configurations are missing. In another word, I have jobs created just with job names, I need to refill everything else. This is essentially useless.
I googled and did not see any related errors. Anyone have any good advice on copy jenkins folders ? I am jenkins 1.651.3, ubuntu 14.04
I tried the same on jenkins 2.19.1 and worked with out the issue your are seeing.
The best way to create similar array of jobs for new branches is via groovy & using https://jenkinsci.github.io/job-dsl-plugin/
create a job where you execute a groovy script to iterate over a list of branches and creates jobs .
DSL plugin is available for jenkins 1.642 and above
Note that manipulating content in JENKINS_HOME is not advised and is typically restricted
I should also mentioned it turns out just our computer issue. Lack of ram. After we added more ram, it' all working perfectly!
JENKINS
I am noticing that the every time I run one of my jobs in Jenkins, there are two files created in the /workspace/build/distributions dir. The two files have the extensions of .tar and .tgz. Every time, I run the job, another set of these files are created. So, if I run the job 3 times, there will be 6 files all together. I have noticed that during the dependency check phase, these artifacts slow things down. Therefore, I wanted to remove them automatically before each time this job runs. I have attempted the configs in the image below. In addition, I have tried the workspace cleanup plugin and that completely deleted the workspace. That is definitely not what I wanted.
Therefore, what would be the best way to go about this.
What scm plugin are you using? Some of the scm plugins allow you to clean the workspace before an update (e.g. SVN's "Emulate clean checkout" and Git's "Clean before checkout" options).
If you're not using a scm plugin, can you remove the files in a batch/shell script during the first build step?
Or perhaps you can go about it from the reverse direction. Can you get rid of the files as the last build step of the job? That way, they are gone when the next build comes along.
I am setting up develop environment for java project.
And my team decide to use Jenkins for CI, and AWS EC2(linux) for server.
I succeeded to make an war file by jenkins job.
But, I can't find a way how to copy war file to EC2, and restart tomcat server on EC2.
I googled about it using "jenkins ec2 deploy", but in fail.
somebody help me!
Step 1. Install Jenkins plugin
Open your favorite browser and navigate to Jenkins. Log in and select “Manage Jenkins” followed by “Manage Plugins”. Select the “Available” tab, locate the “Deploy to container” plugin and install it.
Step 2. Edit tomcat-users.xml
In order for Tomcat to accept remote deployments, you have to add a user with the role manager-script. To do so, edit the file ../conf/tomcat-users.xml and add the following line:
<user username="deployer" password="deployer" roles="manager-script" />
Step 3. Edit the Jenkins job
Back in Jenkins, go to your job and select “Configure”. Next, scroll down to the bottom of the page to the “Post-build Actions”. Select the option “Deploy war/ear to a container” from the “Add post-build action” dropdown button. Fill in the new fields.
Step 4. Run the Job project and verify the end results
Schedule a build for your job in Jenkins. If you check out the log file you should see one or more lines near the end indicating that the war file has been deployed.
If you check the logfiles in Tomcat (catalina.out) you should also see that your application has been succesfully deployed.
Lastly, if you point your browser to the URL and context path you’ve specified in the job configuration in Jenkins (e.g., http://your-server:8080/mywebapp), you should be able to open your freshly deployed application.
Credits to Jdev.it
More info can be found here
With EC2 (or any other deployment practice too), first determine your production servers are going to be mutable or immutable.
[Mutable]
The servers will be running forever, and you perform on-going updates as explained in the blogpost mentioned above (elizabetht) for Java war, or many other ways for different languages/platform.
[Immutable]
The servers are re-created (vs. upgraded) by automation mechanism such as scripting, or using config. mgmt tools like Puppet/Chef/Ansible or vendor specific initialization mechanism like AWS Userdata/Docker dockerfile/Vagrant vagrantfile, or using many other provisioning tools.
Generally speaking databases or queues should be Mutable category, and all other compute nodes are better be Immutable category. The benefits of Immutable category are a lot including easy HA, disaster recovery and also enables Blue/Green deployment and much more.