Could you please let me know what precautions need to be taken while upgrading Jenkins from 1.631 to 1.651.3 other than config.xml of Jenkins and Jobs along with Plugins.
I have 'n' no# of jobs configuration and how to achieve the roll back.
It is recommended to check change-log from official site first, as people use different functions / plugins in different way. And you can install the new version in different host, to check your jobs before applying to production env.
Related
I'm trying to set up a build using Multibranch. I'm basically having the same problem as stated here, but our SCM is Subversion. The Bug in the Bitbucket Branch Source Plugin as described here can therefore be ruled out, especially since our Jenkins has the newest version installed anyway.
I tried to find a similar ticket regarding my problem, but couldn't find one, so here I am.
As this particular project is configured in a way that configuration files (including something like the Jenkinsfile) are to be stored in a subfolder, I don't know what else to try, apart from configuring individual jobs. I'd rather stick to using Multipipelines, however, as they help keeping the build jobs tidy.
This is a not related to code fix, but a general approach for test automation.
I have a test automation written in javascript which runs perfectly on my machine as well as my local jenkins.
Now, i want to use my company's server(centOS) and jenkins so that it is accessible to everyone in my organization.
Issue: nodejs version in company's server need update to run my automation, but server team wont do it since they are not sure if any other functionality used be other teams may start to break because of the upgrade.
Have you faced this situation. Do you have different servers for core code and automation scripts. Please suggest.
This is a complex situation that really depends on many variables. I would recommend using an agent that contains the proper version of Nodejs. With this solution you can leave the current build server how it is but you can also use the exact version of node you need. This will require an extra server/VM with the Jenkins slave software but this will remove the need to change the master server.
The solution my company went with is using Jenkins 2.x with Declarative pipelines and ephemeral Docker containers for builds. This allows you to use any Docker image such as the official Node image. You can pin a version and build it with that. With this there is no need to worry about the version on the server. Jenkins Master doesn't even need to actually build.
I am looking for a way to add/remove/update Jenkins master environment variables using some way of configuration management.
If this can be done with Ansible even better.
Please note that I would like to avoid patching the config.xml file manually, especially because this would risk to create issues and a Jenkins restart would be required and this is to be avoided whenever is possible.
In case it was not clear, I am trying to find an automation solution for altering Manage Jenkins - Configure System - Global properties.
you can configure all your Jenkins master using groovy.
I just did the same when we upgrade to Jenkins 2.
here are some links : https://pghalliday.com/jenkins/groovy/sonar/chef/configuration/management/2014/09/21/some-useful-jenkins-groovy-scripts.html
https://github.com/DotCi/jenkinsci-dotci-example/blob/master/configure-dotci.groovy
https://gist.github.com/vrivellino/97954495938e38421ba4504049fd44ea
BTW , you can install your plugins using CLI it will save you time in the future.
and you can create all your jobs using DSL , so all changes will be in github.
if you have specific question , let me know
can some one explain some steps how to upgrade Jenkins manually in production where server doesn't have any internet. what precautions do we need to take for production env before upgrading. How to manage plugins upgrade too if there is no internet
thanks....
So there are multiple options. Blue-Green, Regular Upgrade, Advance Test Upgrade
Blue-Green - Spin up another instance of Jenkins for the desired version. Copy plugins, jobs directories from PROD to new Instance of Jenkins. Verify the setup is working as expected. Apply any patches specific to version if required. E.G: Upgrade incompatible plugins specific to new Jenkins version. Test all types of Jobs. Finally Make the newly installed instance as PROD and make the existing as passive. You can repeat the same exercise in future and the passive becomes active in future. Infact you can put a Apache Reverse proxy infront of both instances, and make your Apache point to the desired instance for PROD.
Regular Upgrade - Inform all required and impacted parties. Take an approval for the downtime. Take the backup of you JENKINS_HOME. Make a note of Plugins that are incompatible in newer version of Jenkins. Upgrade to new version. Replace the incompatible plugins with supported version and finally test the jobs. Worst case if you are running out of time rollback to backup version.
Advance Test Upgrade - Copy the Jenkins_HOME. Install Jenkins new version on some other machine. Copy the jobs,workspace, plugins and config.xml. Verify the new instance is working. Make a note of things that you followed for the upgrade. Next take an approval for Downtime of PROD jenkins. Upgrade Jenkins based on the above steps.
Please comment if you need additional details specific to any of the above 3 options
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.