We are using jenkins pipeline and groovy scripts to do automated build pipeline steps.
However, jenkins has decided to cache previous version of these script files and I have yet to figure out how to clear this cache or how to force load the newer version of these scripts.
The scripts are coming from a git repository and executed through a Jenkninsfile bootstrapper loading scripts using the myscript = load "#script/path/to/script.groovy" syntax.
It is these script.groovy files that are not "updated".
Well, we had it sorted out. Someone changed the casing on on of the folders.
Jenkins does not delete the previous folder, but keeps it. Scripts were still pointing to the previous cased folder but jenkins was pulling the updates to the new cased folder.
Related
I have this log4j-1.2.12.jar file in my jenkins server
Path to it: /data/jenkins/.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar I got this Apache Log4j Unsupported Version Detection message from security team, how to resolve this I tried downloading the latest version but it is something like this log4j-api-2.19.0.jar
No, it's not "in Jenkins", more accurately, log4j is not a part of Jenkins. Jenkins consumes its jars from the exploded war in ${JENKINS_HOME}/war/WEB-INF/lib. It is not located there.
If a plugin consumes log4j, that would be found within the exploded plugin directory at ${JENKINS_HOME}/plugins/<plugin_name>/WEB-INF/lib. The status of log4j as it related to most plugins was tracked under JENKINS-67353.
What you are referencing is the maven local repository, .m2/repository. This structure is created when running a maven build on the controller; the dependency jars specified in (one of) your build's pom.xml.
The guidance in the comments is correct; find the appropriate pom.xml and update it, then rebuild.
You can verify these claims by deleting the entire .m2 directory (or moving / zip;delete if you are paranoid) and restarting Jenkins. You'll discover Jenkins is running fine and the directory remains empty. Run your maven jobs and it will repopulate, including log4j-1.2.12.jar, assuming it's still specified in your pom.xml. Fix your maven pom.xml, delete the directory, rerun your jobs and it should not reappear.
Perhaps you have already updated your pom.xml but never cleared out your local maven repository, then it will not repopulate (you could check the timestamp of the directory to know when it was first/last downloaded).
You can also delete referenced portions of the repository by specifying mvn dependency:purge-local-repository and adding -DreResolve=false to avoid re-resolving. Of course, if you've already updated the pom.xml, it would remain since it's not referenced in the pom.xml` (yes, it would be nice if there was an option to purge all or most of a repository or all version of a given jar, but ...).
We have an old jenkins v2.138 upgraded to v2.332. with this upgrade, there is a change related with workspace structure.
with v2.138, it was like /jenkins_home/workspace/jobaaa-SFSBDFEXXXXXXXXXXX#script/pom.xml
with v2.332, it is now /jenkins_home/workspace/jobaaa#script/SFSBDFEXXXXXXXXXXX/pom.xml
with this change, our pipeline script fileexist("pom.xml") doesn't work anymore.
If we don't want to change our pipeline script, is there any setting to set back the workspace structure as in v2.138.
Thank you very much for any input!
We have a master and two slaves.
On Master there is a job which checks if there is new version on Nexus and if yes downloads latest jar and updates latest version (i.e. xxx-0.012.jar) in text file VERSION.TXT. (It is possible to access nexus only from master).
We need to run downloaded jar on slaves so we need to copy it from master.
We have a job which triggers few other jobs:
1)CHECK_LATEST_JAR: job which runs on master and checks if there is new version of jar on nexus, downloads it.
2)GET_JAR_TO_SLAVE: job which runs on slaves and should copy latest jar from master
3)RUN_JAR: job which gets latest jar name from file VERSION.TXT and runs jar with such name.
In CHECK_LATEST_JAR if newer version is found on nexus we download it to workspace and archive artifacts (jar + text file with latest version).
Now in GET_JAR_TO_SLAVE we wanted to use "Copy artifacts from another job" plugin - but here we need to add a condition to run this step only if there is newer version as if there are no artifacts in CHECK_LATEST_JAR this job fails..
Is there a way to compare file which is located on master with file which is located on slave?
Tried to use conditional step with groovy script - but cannot figure out how to tell it to access file on master if job runs on slave.
Just came across FSTrigger plugin which probably can be used - but same problem here how to tell it to monitor file VERSION.TXT on master and if there is a change to run job on slave.
would be grateful for any ideas how we can achieve our goal.
thanks
We found plugin Copy Data to Workspace and used it to copy file containing latest version from folder on Master to workspace of job running on one of slaves.
After that we compare content of files using Conditional BuildStep plugin strings comparison with Token macro and if files content is different we copy artifacts of the job where jar is downloaded.
Does anyone know how I can remove jenkins plugins from a script? I know there is no CLI command that exists for it. But was wondering, maybe you can just delete the plugin folder, and attempt to delete all associated data.
Reason I want this, is I want to develop a script that will run nightly. It will scan each Jenkins server, remove plugins if not found in file stored in GIT, it will add plugins if new ones are added, and upgrade or downgrade other plugins if the version doesn't match. The goal is to keep all Jenkins servers in sync as far as plugins go.
Any thoughts on how I can achieve this goal?
groovy script for removing a plugin:
String pluginNameToRemove = "myPluginToRemove"
def jenkins = Jenkins.getInstance()
def pluginManager = jenkins.getPluginManager()
def pluginWrapperToUninstall = pluginManager.getPlugin(pluginNameToRemove)
pluginWrapperToUninstall.doDoUninstall()
You can also remove the content of the plugins folder, download all the plugins you want according to the file, copy them to the plugins folder and restart jenkins. (We have a very similar flow on our environment for deploying jenkins instances)
I am new to Jenkins and just started configuring it. This is what i have done till now:
Installed and configured Jenkins to display the home page. Added PMD plugin.
Set the HUDSON_HOME to a specific directory > C:\Work\Jenkins
Configured a test build to run a simple do-nothing ant script. It runs successfully
Written an independent pmdbuild.xml to run checks on a set of files in C:\myview (I am using clearcase). This xml also copies the output pmd_results.xml to the workspace directory in $HUDSON_HOME/[job-name]/workspace
Now I added the pmdbuild.xml as a step in my primary build. So my build has 2 steps:
a. Run a simple script, do-nothing.
b. Run pmdbuild.xml which generate pmd_results.xml and place it in $HUDSON_HOME/[job-name]/workspace (HARD-CODED as Jenkins PMD plugin expects the file there)
Jenkins picks up the pmd_results.xml automatically with the plugin and displays warnings and everything.
Now the problem:
If I click on a filename in the PMD results, it gives a filenotfound exception as it is looking for the source file in $HUDSON_HOME/[job-name]/workspace.
My java code files are placed in C:\myview (a clearcase snapshot view)
My question is, do I need all my code files to be present inside $HUDSON_HOME/[job-name]/workspace ?? Meaning can't I tell Jenkins to look for the PMD input files in C:\myview or any other directory instead of $HUDSON_HOME/[job-name]/workspace ??
Sorry for the extremely long description.
Jenkins expects that all the code is in the workspace. Usually Jenkins is used to check out a copy of the code into the workspace, and then runs all build steps on the Sources in the Workspace.
Might seem restraining at first, but it saves you a lot of trouble if you need to move Jenkins to another server, or create a slave instance.
So I would suggest you let Jenkins check out your code (there should be a clearcase plugin) into the workspace, and run the analysis on the checked out code.
If there are compelling reasons why your code has to stay where it is (C:\myview in your case) you can still set the workspace of your build to that directory (find this in the job configuration page, you need to click on the 'extended' button to see the option).