I have a large fleet of Jenkins instances running in a cluster, all having the LDAP plugin version 1.6 (Jenkins version 1.611). I want to fleet-upgrade the LDAP plugin version to 1.7 (to incorporate environment variables in my plugin configuration). How do I achieve this without manually uploading 1.7 version through UI for each Jenkins instance?
I tried writing a script which basically performs these operations for each Jenkins instance:
Replace the existing .jpi/.hpi file in $JENKINS_HOME/plugins for ldap plugin with the correct .hpi file (of the 1.7 version)
Edit config.xml under $JENKINS_HOME which has the version number
Safe restart Jenkins
It works fine till step 2 but as soon as I perform safe restart, Jenkins magically puts in the original .jpi/.hpi file (the 1.6 version file) back inside $JENKINS_HOME/plugins. Jenkins instance has the 1.6 plugin version again in the UI. Is there a better way to perform fleet plugin upgrades in general? I want to mention that I want the 1.7 plugin version, not the latest
How do I fix this? I even tried using curl (mentioned at https://stackoverflow.com/a/20848745/1746529) but didn't help.
Got a working answer on Google groups.
"As you are on 1.x create an empty ldap.jpi.pinned file as a sibling and that marker will instruct Jenkins not to replace with the bundled plugin."
Came across the documentation for it as well - https://wiki.jenkins-ci.org/display/JENKINS/Pinned+Plugins
Related
After moving Jenkins to a new computer I cannot upgrade plugins since it thinks the new version is older than the installer.
I get the following message:
Some plugins could not be loaded due to unsatisfied dependencies. Fix these issues and restart Jenkins to re-enable these plugins.
Dependency errors:
Static Analysis Utilities (1.96)
Update required: Maven Integration plugin (2.12.1) to be updated to 2.17 or higher
Update required: Matrix Project Plugin (1.6) to be updated to 1.7.1 or higher
Update required: OWASP Markup Formatter Plugin (1.3) to be updated to 1.5 or higher
and several more.
I then try to upgarde Maven INtegration polugin (and alla others) it looks like the are installed and Jenkins is restarted. But I get the same error again.
When looking in the plugin folder I see that I have several version of the plugin. I try to remove the different folders and then detect that the old verision is still used even if the new version is available in the folder.
In the pluginmanager/installed the Maven Integration plugin is listed as version 2.12.1 and the possibility to DOWNGRADE to 3.8. 3.8 is the version that I upgrade to.
My conclusion is that during the move of the .jenkins folder to the new computer the dates of the old plugins are getting new values which confuses Jenkins. Is that a correct conclusion? How can I correct it?
Since the folder dates were changed long ago at the old computer I was not able to zip the old .jenkins folder with "correct" dates
However, I found a way forward anyway. I did like this:
Started with a newly installed Jenkins version.
Made sure I had all necessary plugins in the new Jenkins installation
Copied the following folders from the old computers .jenkins zip file:
jobs
nodes
secrets
users
workspace
Then I also moved the files in the .jenkins folder
I added the Marathon plugin to Jenkins through the Jenkins management Web UI. It showed up as a list of available plugins to install. I also downloaded the HPI and added the plugin manually. In both cases, the Marathon option doesn't show up in my pipeline config. I'm following the steps here: https://dcos.io/docs/1.7/usage/tutorials/jenkins/#building-a-docker-image-and-deploying-it-to-marathon
Use version mesosphere/jenkins:3.0.1-2.32.2 in combination with persisting your Jenkins data on NFS. Installation and updates of plugins works for me with this combination.
You should consider missing functionality in older versions of Jenkins in DC/OS as described in this thread: https://github.com/mesosphere/dcos-jenkins-service/issues/105
Do you use a NFS share to persist your Jenkins data? In my experience you can not use DC/OS Jenkins properly without persisting Jenkins' data.
I have installed Jenkins plugins in two ways i.e. manually keeping the .hpi file in Jenkins home directory, and installing from Jenkins front-end (Manage Jenkins > Manage Plugins).
What I notice here is when I install the plugin manually (downloaded as .hpi file) it installed with extension .hpi and while installing the plugin through Jenkins front-end I notice that plugin again installed as .jpi.
But why? What is going on in the background? I know functionality won't change but it looks interesting to know.
Both are supposed to be identical to that extend that Jenkins is renaming hpi to jpi when you install it manually as you said.
The reason why you see both in your JENKINS_HOME is the order in which plugins are loaded when Jenkins boots up: plugin.jpi gets precedence over plugin.hpi in case both are present. This is the way the upload installation makes sure the uploaded version will override the existing one after the restart.
Well I think its because Jenkins forked from Hudson so that is the 'H' in hpi. The J is obviously a change to that.
In terms of technology, the jpi plugins are generated using the gradle plugin architecture and hpi plugins are generated with the Maven architecture
Ultimately, as you have found both produce plugins which Jenkins can use. The vast majority are built using Maven but I am a fan of Gradle as it links nicely in with developing plugins in Groovy. You can also build in Groovy using Maven
Plugins as present in $JENKINS_HOME/plugins/ should always be using the .jpi suffix (with the basename being the plugin identifier). Normally Jenkins will enforce this naming pattern even when uploading a plugin manually, regardless of what filename you used for the upload, so I am not sure how you came to have a *.hpi file here, unless you directly copied it into this filesystem location.
I currently have Build User Vars Plugin 1.1 installed in my Jenkins. Since version 1.1 of the plugin, there has been some important changes to the plugin code, and I want to pick them up. The question is what is the least amount of work to package up the hpi/jpi file that I can push on my Jenkins install that will contain latest changes.
It's fairly easy to build a plugin locally; you can then upload the hpi/jpi file to Jenkins via the Advanced tab in the plugin manager.
See the Jenkins plugin tutorial for detailed steps.
I've set up Jenkins as a service on my Windows 7 developer PC in order to provide rational arguments to why we should use Jenkins and not Bamboo in the company.
I've installed the 'Analysis Collector Plugin': https://wiki.jenkins-ci.org/display/JENKINS/Analysis+Collector+Plugin, but Jenkins ignores my configuration of the trend graph:
After I save the config, it still displays the default graph with the default settings:
I know the graph settings are stored as cookies, which is why I use the URL http://127.0.0.1:8080 instead of http://localhost:8080, but still I can't get it to display the right graph.
Jenkins v1.538
Static Analysis Collector Plug-in v1.38
This issue has since been resolved in later versions of the Static Analysis Plugin. Please download and install the latest version 1.51 and upon restart the issue should be resolved.
There is an interdependency of this plugin with the Static Code Analysis Plugin, so you will need to update that plugin to the latest version as well.
Lastly, and most importantly, you will need to (and should anyway) update Jenkins from version 1.538 to a more recent version to remain compatible with the newest version of the Analysis Collector Plugin. For this reason (as well as many others), I highly reccomend the latest version of Jenkins as well, which at the time of writing this is 2.63.