I am using Jenkins CI in my project, I am able to successfully build the project and I have no issues in deploying it in the container after every successful build. Now I have a condition that the deployment to the container has to happen only if there is a change in the release properties file. If there is no change in the release properties file then the project has to be built but no deployment should happen.
Since I am new to Jenkins I am trying out all the options, I am sure that someone must have been in the similar situation, please share your thoughts or ideas. Incase if I find something I will post it.
Highly Appreciate your help on this.
If this is still not answered!!
This can we easily done using Script Trigger plugin.
This allows you to run a shell/batch script and based on the exit code of this script the build will be executed.
You can keep track of the last modified date of the properties file and if it changed then you can go ahead and build, if not there will not be any build until the change happens.
Hope this helps (if at all required now ;)
You should install the "Post-Build Script Plug-in" in your Jenkins. The previous answer was mentioning a plugin that is no longer available.
Then you can add sub build steps, like executing a shell script
script
You can also publish a Docker container, etc.
Related
I ran a build yesterday, hoping I would read some logs today.
I came today, and got an error 404 when trying to access the build. Strange.
Running another build, shows my build actually did run, but it is unreachable.
Is there a way to get my hands on the logs?
Notice build #10 is missing, even though it did start.
Probably a windows update is to blame for this.
The broken link is http://192.168.80.10:8080/job/Dev_git/10
More information on a run can usually be found using the context menu under Console Output. This is only accessible if you have the correct permissions set in Jenkins.
This of course does not work, if a build is missing. One reason could be that your Jenkins is configured in a way that only a certain number of historic builds are kept, see Build History Missing in Jenkins for an explanation how to deal with that.
However, your case seems to be different, because a build in the middle of the history is missing. For this, I suggest to look around in the jobs directory of your Jenkins installation where it stores all the configuration and run data.
References
https://wiki.jenkins.io/display/JENKINS/Administering+Jenkins
Where does Jenkins store configuration files for the jobs it runs?
I'm new to jenkins.
For that sake I installed the latest version of jenkins i.e. 1.632 on my ubuntu and deployed a war using post build actions in the configuration part. That worked fine for me.
Then I changed a few things in the build making sure that it fails when deployed and it effectively did and I'm not able to access the application die to deployment failure.
But I'm curious here, I have heard that in case of a build failure jenkins makes sure that the previous build remains deployed so that the application is always up and running. Please clarify if I'm wrong or doing anything wrong in my deployment steps.
I did searched a lot about this but couldn't find a valuable answer.
Haven't done much with the deploy plugin but it states this in the docs
Now when you trigger this job you can enter the build number (or use
any other available selector) to select which build to redeploy.
So you can set up a build on failure which will redeploy the last stable version. Here is also an example how to get the last stable build number:
http://<JENKINS>/job/<JOB_NAME>/lastStableBuild/buildNumber
I am on a redhat linux box. I recently updated Jenkins to version 1.509 only to find that after doing so it has "forgotten" two of my jobs/projects. The jobs can still be found on my Jenkins machine under /var/lib/jenkins/jobs, but they no longer show up in the Jenkins GUI. I attempted to re-create them based off the configuration file I have, but I am not confident I have totally re-created the functionality they had.
I also tried to copy the job and or rename it hoping that would get jenkins to see it, but no luck. I had tried cp -r /var/lib/jenkins/jobs/JOB1 /var/lib/jenkins/jobs/JOB2. I also restarted the service a number of times. Finally I updated all of my plugins on the off chance that was somehow related.
So my question is "How can I get Jenkins to notice these jobs?" or failing that "can I run these jobs from in the terminal?"
NOTE: I am not discouraging others from upgrading Jenkins. After I upgraded Jenkins did complain about a number of things which I didn't pay enough attention to which I believe got me into this mess in the first place.
If I were you, I would try the Jenkins CLI (from $JENKINS_URL/cli) and use the create-job command and feed the job configuration file to the cli's stdin.
If that does not help, I would inspect Jenkins log files (you are saving stdout and stderr of Jenkins somewhere, right?) for any errors or clues. If the job failed to load because of some tag that you can guess is provided by a plugin, try to remove that part from the config file.
If that does not help, I would upgrade Jenkins. I think there might be some fixes related to this in the LTS version changelog since 1.509.
And above all... if I were you, I would start making backups of the job configuration files.
I regularly back up the global config.xml, all the job config.xml files and all the plugins. Using these I can set up my Jenkins from scratch. And I do that to set up a test instance where I try any plugin or Jenkins core upgrade. If I see no problems after running a few of the trickiest builds, I know I can upgrade the production instance with much more confidence.
I have a multi-module maven project that I'm building with Jenkins called MyApp. I also have another maven project that depends on MyApp, and this project runs integration tests on MyApp.
In Jenkins, when I view the status of the MyApp project it successfully displays a list of previously run builds and I can click on them to find out more information (and view the console output).
However, the integration test project, while it does build properly, it only displays previously run builds for about 5 minutes, at which point something happens and jenkins completely forgets the build ever ran.
On the filesystem, I am able to cd to:
/usr/share/tomcat6/.jenkins/jobs/My App Integration Test/builds
and ls reveals
me#myserver:/usr/share/tomcat6/.jenkins/jobs/My App Integration Test/builds$ ls
1 2 2013-01-24_16-46-59 2013-01-24_16-51-58 2013-01-24_18-05-09 2013-01-24_18-58-46 3 4
that all my previously run builds are right there, where they should be.
Jenkins has a "discard old builds" feature in its project configuration page, but I obviously have it unchecked.
I'm running jenkins in tomcat6 on Ubuntu.
Help please?
Jenkins has resolved this issue as of 1.505 I recommend everyone upgrade who does not wish to switch from Jenkins back to Hudson.
This can be done through the GUI via Manage Jenkins->Upgrade to Latest (Note for this to work you need to have the appropriate permissions for Jenkins)
More information can be found here For linux users aptitude update or yum update jenkins should also work for you.
I have jenkins running with 1.517, still facing the issue if the number of builds goes more than 65 without discard option. Found that reload configuration bring back the build history.
I've seen this issue and have always been able to resolve it by following these steps:
Going to \\[buildmachine]\C$\Jenkins\jobs\[jobname]
Removing the builds folder.
Removing shortcuts to lastStable and lastSuccessful.
Open file nextBuildNumber and change the number to 1.
Then build new jobs and they no longer disappear.
As mentioned by Dave Bacher, this appears to be a bug in Jenkins. I switched over to Hudson and problem fixed!
I'm already finishing my project build automation :) with Hudson and Nant.
My project structure is something like
$/Project
build.scripts
script1.build
script2.build
build.properties.xml
Code
Project1
Project2
So Hudson downloads from the root $/Project to the workspace folder.
And everything is ok since the build.scripts are in the workspace, I run them very easily, however what is bugging me is the fact that since the build scripts are inside the workspace, then I can't program Hudson to run automatically either based on time or changes because it will always detect changes to the files (note build.properties.xml which I check out and check in at build time to store some stats).
Where do you recommend these files to go in and still get the advantage of having them source-controlled?
What I ended up doing is to NOT check-in changes to those files. I changed my CI workflow to create another file (local to the workspace only) where the changes are written to.
This way, I still get the last build info written somewhere to pick it up, and avoid the issue of Jenkins detecting the change.
PS: I changed from Hudson to Jenkins since I saw that most plugins ran away from the former. The transition was too smooth to be true.