I recently made available Amazon Corretto 11.0.12.7.1 with the name OpenJDK11Latest on the Jenkins Global Tool Configuration Page auto installed with extract .zip/.tar.gz
My requirements changed and I now have to use Oracle's 11.0.2 version instead. However, when I swapped the image the build still failed due to the Amazon Corretto version still existing in the OpenJDK11Latest directory (the extracted subdirectory is named differently for the different versions).
I am able to fix this by creating a new JDK that is named differently, but this is very suboptimal as I have to then change where it is used in my pipeline definitions (around 8 places).
How can I force the re-download of this JDK in my builds. I have future concerns in case we want to upgrade the version again or we do actually end up replacing it in the end.
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
Last time I've upgraded Stash Pullrequest Builder Plugin to version 1.9 and after that any triggered build has empty parameter list (parameter variables like ${pullRequestId} specified in documentation are not available: https://github.com/jenkinsci/stash-pullrequest-builder-plugin/blob/master/README.md). Now I've tried version 1.10 and have the same issue. With version 1.8 everything is working fine.
1.8:
1.9 / 1.10:
I am using Jenkins in version 2.180 and Git Plugin in version 3.10.0
Maybe some of you experienced the same issue? I would be appreciated for any help.
Jenkins was changed in version 2.3 to disallow adding parameters to a build if they are not declared in the project configuration. The motivation was to prevent a security issue when a project controlled by an attacker invokes another project with arbitrary parameters. Since the parameters are seen as environment variables by the build scripts, the attacker could make the build load an untrusted library. Since its possible for different projects to be controlled by different users and run with different privileges, such behavior would allow the attacker to exploit permissions of a project he or she is not allowed to configure. The issue is known as SECURITY-170.
Stash Pull Request Builder was adding 10 parameters to the build to provide information about the pull request being built. Following the SECURITY-170 implementation, the plugin was changed in version 1.7.0 to pass those values as environment variables as well. Those environment variables are recorded to the build history. They can be viewed if Build Environment Plugin is installed.
Starting with version 1.9, Stash Pull Request Builder plugin removed the old mechanism of passing pull request data through parameters, as it was causing a large number of warnings in the Jenkins log.
The plugin's README.md file has just been updated to use the term "environment variables" to avoid confusion.
If you really need parameters, you can define them for the project. Starting with the next version of the plugin (presumably 1.11), the configured parameters will be populated with the same values that are available through the environment variables.
When upgrading Jenkins via replacement WAR file when we go into Jenkins all is showing correctly as the new updated version. However, The Windows Control Panel "Programs & Features" Still shows as the original version which was fully installed.
is there a way this can be updated (registry) as I'm concerned that an future scans of our system for old software will still flag this up.
This has turned out to not be an issue as the health checking software does not look at this.
I'd like to build ImageMagick for use with CloudBees. Normally, you would use a package manager like apt, yum, or homebrew to install it. However, on CloudBees you don't have admin access or access to these tools.
I've tried including ImageMagick as part of my build process - however it's linked to use the directory it's built out of "/jenkins/somethingsomething". At runtime it fails to find its libraries. The run-environment is a separate machine, in a directory "/apps/
I've tried building it from source as part of the deploy process, but this causes the deployments to timeout.
Is there any way to build ImageMagick so that it looks in $MAGICK_HOME at runtime instead of binding to a specific, hard-coded path?
Thanks!
Chris
On development environment, using Jenkins on DEV#cloud, you can try to use it through "curl" command for example. However, on runtime you can only use it, if you customize the stack you want to use.
CloudBees has created stacks for Tomcat, JBoss, Jetty and Glassfish. For example, Tomcat 6 and Tomcat 7 stacks used by CloudBees on runtime are available on GitHub (here) on different branches.
More information about ClickStacks is available here. Also the way in which you can customize your own stack, Developing and using your own ClickStacks section.
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.