My Jenkins instance interface broken. I suspect recent plugin update as the cause. However I cannot remember which plugins get updated recently. I need to know so I can rollback plugin version to the previous one.
How to find this information?
Some possible way:
Jenkins log
Retrieving plugins info via Groovy console
In my opinion, the most efficient way is go to the $JENKINS_HOME/plugins directory, then issue command:
ls -alt *.hpi *.jpi
and the most recently update/installed plugins are ranking at the top of the results, hope this helps.
Create a job scheduled to run daily, that logs the plugins and versions. There are several ways to do this, and it seems that none are straightforward or obvious. The method I've settled on simply archives the output file of this command:
curl -kLsS "${JENKINS_URL}pluginManager/api/json?pretty=1&tree=plugins\[shortName,longName,version\]" \
> plugin-list.txt
That give an easily accessible history from the Jenkins web UI. (Or on-disk if you know where to look.)
Diffs comparing previous version(s) left as an exercise for the reader.
Related
I am quite new to Jenkins. I installed it but unfortunately I did not install any Plugins.
How can I get the suggested plugins installed on a running Jenkins environment?
The short answer is: you can just go to the "Manage plugins" ( ${JENKINS_URL}/pluginManager/ ) and pick them (see caveat) yourself according to your needs. The master suggested plugins list is available here.
It would seem this has been answered here before, but not accepted.
Depending if you have a previous install or have upgraded from a prior version,
you may see the following line in the ${JENKINS_HOME}/config.xml:
From:<installStateName>RUNNING</installStateName>
AND/OR the following files in the ${JENKINS_HOME} directory:
jenkins.install.UpgradeWizard.state
jenkins.install.InstallUtil.lastExecVersion
Removing the files and/or changing the config.xml to:<installStateName>NEW</installStateName> will reinstate the InstallWizrd. Only remove or change whatever exists; do not add anything. The files are created when you Save and Close the Wizard.
Storing the Jenkins version (ie: 2.303.2) into the two files will bypass the InstallWizard.
See #VonC's response for Docker images.
I am having issues using Maven's: mvn dependency:purge-local-repository command.
I have several versions of a project and would like to remove certain versions.
I am running the command:
mvn dependency:purge-local-repository -DactTransitively=false -DreResolve=false -DresolutionFuzziness=version
The command runs with success but nothing is purged(deleted) from my local .m2 repository.
I have closely watched the windows explorer while the command runs, and I see items being deleted, repopulated, and deleted again, but in the end nothing has changed and the same files I wanted gone remain.
Can anyone explain what I am missing, or not fully understanding of how to use the tool?
thanks,
Cameron
I am having an issue with .HPI(jenkins Plugin) and so far no one is able to help me.
JENKINS .HPI dependencies issue << click on this link
so now i am wondering , is there a way that,
When using my .HPI(jenkins Plugin) in jenkins, I can run it in a debug or verbose mode, so i can see on the Console Output(in jenkins) what is exactly that is going on.
I think i am getting an error cause it is not going to the right .jar ....
when i ran it in eclipse I have no issue. ( i know which jar it is going to in debug mode in eclipse)
if you cannot run the .HPI(jenkins Plugin) in a verbose or debug mode in jenkins , maybe i can run it as a .WAR ? in a verbose or debug mode in jenkins ?
since i have read that .HPI is very similar to a .WAR.
so that way i can see in the output console exactly what .jar it is going to.
If someone can help me or point me in a direction it will be really helpful.
Try a debug from Eclipse! If it's not working, just add some logs to your project and when you run it in Jenkins, take a look at the logs in console ( easy if you start Jenkins from command line). Or, in the Jenkins installation folder there should be some log files.
Next time can you put the question more clear? It's somehow hard to understand what you ask.
Yes, I read your questions. I'm not sure if you'll can see which jar/ lib is chose by Jenkins.
But, about the link,previous question, I had a problem somehow like you with some libraries and tests, when I worked as plugin developer. I'm not sure if I remember correctly, but, just try, create a folder in your project, let's say libs, put the jars in that folder and add the folder to build-path in eclipse and maven should take care of them.
Not sure if it'll work, but you should try. Sorry I can't help you more!
Is it possible to use ThymeLeaf with Grails 2.4?
There is a plugin that was started (https://grails.org/plugins/pending/250), but it doesn't appear to be active anymore and it noted some significant issues.
I've done quite a bit of searching and haven't been able to find anything on this subject other than the abandoned plugin... maybe I should take that as a sign.
Try it out and see. Clone the repo, then edit ThymeleafGrailsPlugin.groovy and change the version to a -SNAPSHOT version:
def version = "0.1-SNAPSHOT"
Then run grails compile and grails maven-install. That second script will build the plugin and copy it to your local Maven cache in the same format as if it were retrieved as a published plugin.
To use it in a project, add it like any released plugin, e.g.
compile ':thymeleaf:0.1-SNAPSHOT'
and it will resolve from your Maven cache.
To make changes, leave the version but run clean and maven-install again, but delete the plugin directory in the cache. That'll be something like $HOME/.m2/repository/org/grails/plugins/thymeleaf/0.1-SNAPSHOT - delete the whole directory, and after rebuilding the new version will be used.
David's email is in ThymeleafGrailsPlugin.groovy if you get stuck. It's easy to miss comments in the plugin proposal pages, so don't take a lack of a reply there as an indication that the plugin is totally abandoned.
I have about 100 jobs on my hudson CI, possible to mass delete them ?
The easiest way, IMHO, would be to use script. Go to http://your.hudson.url/script/
Delete jobs by running:
for(j in hudson.model.Hudson.theInstance.getProjects()) {
j.delete();
}
And this way gives you an option to easily use condition to filter out jobs to delete.
FOR JENKINS
Current versions (2.x):
for(j in jenkins.model.Jenkins.theInstance.getAllItems()) {
j.delete()
}
Older versions:
for(j in jenkins.model.Jenkins.getInstance().getProjects()) {
j.delete();
}
Just delete the job directories:
cd $HUDSON_HOME/jobs
rm -rf <JOB_NAME>
See: Administering Hudson
You can programmatically use the XML api (or use the JSON flavor if you prefer that):
http://your.hudson.url/api/xml?xpath=//job/name&wrapper=jobs
Returns:
<jobs>
<name>firstJob</name>
<name>secondJob</name>
<!-- etc -->
</jobs>
Now iterate over the job names and do a post request to
http://your.hudson.url/job/your.job.name/doDelete
(You can do this with any programming language you like that supports XML and HTTP)
I had similar manageability problems with a Hudson instance that was running 500+ build jobs - it was impractical to manually maintain that many jobs using the gui. However, you can provision jobs in Hudson remotely and programatically by using the CLI - which is supplied as a jar file [http://wiki.hudson-ci.org/display/HUDSON/Hudson+CLI].
The command to delete a job would be something like:
**java -jar hudson-cli.jar -s http://host:port/ delete-job jobname**
And the rest of the commands you will need are here:
**java -jar hudson-cli.jar -s http://host:port/** help
I wrapped the cli in python and created an XML file from which to hold the build configuration - then I could use this to manipulate my running instances of Hudson. This also provided the ability to 'reset' the CI instance back to a known configuration - handy if you suspect build failures were caused by manual changes in the UI or if you are using a different CI server for each environment you deploy to (ie dev, test, prod) and need to provision a new one.
This has also got me out of a few binds when badly written plugins have mangled Hudson's own XML and I've needed to rebuild my instances. Hudson is also I/O bound and for really loaded instances it is often faster to boot Hudson from scratch and populate it's configuration this way.