Dear Mark,

I want to say thank you for your time and diligent response, our system is used in the production and it is not possible to just remove the old plugins without figuring out if it they are being used or not. How do we identify that? 

If possible, can I please ask you to look at the entire list of my installed plugins provided and give me a summary of which one needs to be upgraded or removed?

Regards,

Harry

hkyupelyan no, I'm sorry, but I'm unwilling to do that for you. The format of the plugin list that you provided is unusable for me. I would have to rework that list into the format specified in the https://community.jenkins.io/t/migrating-jenkins/894/5 where it says:

If you’re unable to identify the plugin with the issue after those steps, then submit an issue to https://issues.jenkins.io that includes the precise list of plugins installed and their versions and the exact steps you take to duplicate the problem. The list of plugin versions is crucial because others will need to duplicate your environment.

If you create the list of plugins and their versions in the correct format (as described at that hyperlink), then you can use something like this script to perform local experiments of your own on that plugins.txt file, without disrupting your production server:

#!/bin/bash
git clean -xffd
mkdir plugins
# Update to latest releases of plugins
java -jar ../jenkins-plugin-manager-2.12.3.jar --jenkins-version 2.303.3 --latest false --plugin-download-directory plugins --plugin-file plugins.txt
JENKINS_HOME=. java -jar ../jenkins-2.303.3.war

Place that script into an empty directory and use git init to create a git repository, then use git add and git commit to add the script file and your plugins.txt file to the git repository. That will allow you to make changes to the script and to the list of plugins while exploring. Download Jenkins 2.303.3 war file and Jenkins plugin manager 2.12.3 into the parent directory and the script will allow you to quickly start a Jenkins controller for experiments with your set of plugins.

If you enable Jenkins Health Advisor by CloudBees, the report would identify any plugins that are impacted by https://support.cloudbees.com/hc/en-us/articles/360058194871

Dear Mark,

After I have updated all my plugins to the latest version, I still have the same problem.

Furthermore, this same error "Either Source files, Exec command or both must be supplied" that I get on the edit jobs configuration page is reported as a major unresolved bug on https://issues.jenkins.io/browse/JENKINS-25122

I also get all of these errors below.

" Empty token, no token will be used."
"Empty URL"
"Empty Key."
"Empty ENV key"
" Please set an environment variable name"
"Please set a version number format string.  For more information, click on the ?."

 The point I am trying to make is that this is a broken jenkins core release build issue and not an isolated plugin.
Kindly please let me know which version of Jenkins core release addressed this issue so we can upgrade to it and address this issue?
Regards,
Harry
 
 

Dear Mark,

According to Jenkins change log https://www.jenkins.io/changelog-stable/

version 2.319.1 (2021-12-01) contains the reference to https://issues.jenkins.io/browse/JENKINS-64072 which the same broken config ui issue we are discussing.

What does this reference mean, was this issue discovered by the community in 2.319.1 release, or it was addressed by jenkins 2.319.1 release?

Regards,

Harry

hkyupelyan you may continue to assert that there is a core Jenkins issue but you have not taken the necessary steps to eliminate the known problems. You can continue asking if there is a core Jenkins release that will resolve your issue. I will continue to answer that there is not a core Jenkins release that will resolve your issue. The issue you're seeing requires that you remove obsolete, outdated, unmaintained, and insecure plugins. Until you've done that, further upgrades of Jenkins core will not resolve the issue.

You said:

After I have updated all my plugins to the latest version, I still have the same problem.

That is one of the required steps. That step is not enough to resolve the issue when you still have plugins installed on the system that are known to have issues with configuration form modernization.

There are multiple steps in the instructions at https://community.jenkins.io/t/migrating-jenkins/894/5 . If you haven't done all the steps, you should not expect a solution to the problem. So long as the Ivy plugin, the ruby runtime plugin, the DRY plugin, the violations plugin, the pmd plugin, and other plugins with known configuration form modernization issues are installed on your system, the problem should be expected to persist.

Would upgrading to the latest Jenkins (2.319.3) resolve this issue for us?

No, it would not, unless you perform all the other steps in the instructions at https://community.jenkins.io/t/migrating-jenkins/894/5 . JENKINS-64072 is not listed as being fixed in Jenkins 2.319.3, it is listed as an open issue reported by an anonymous user. Upgrading to Jenkins 2.319.3 should not be harmful and will let you avoid the risks associated with Jenkins security advisory

hkyupelyan, you asked:

According to Jenkins change log https://www.jenkins.io/changelog-stable/

version 2.319.1 (2021-12-01) contains the reference to https://issues.jenkins.io/browse/JENKINS-64072 which the same broken config ui issue we are discussing.

What does this reference mean, was this issue discovered by the community in 2.319.1 release, or it was addressed by jenkins 2.319.1 release?

JENKINS-64072 is not listed as being fixed in Jenkins 2.319.1, it is listed as an open issue detected by an anonymous user and reported by clicking one of the weather icons and entering the issue number.

Hi Mark,

I do appreciate the quick and candid reply, no matter how painful it might be, you were right it was one of the plugins. The issue I have with this entire approach is that since Jenkins made this effort to convert al of html into divs, Jenkins should release a tool / plugin to detect and identify all of the plugins that are incompatible with html to jenkins div cutover. I am hoping that what I say does not fall on the deaf ears. It is a SOLE responsibility of Jenkins team to release the tool that properly identifies all of the plugins with this problem.

Having said that, I appreciate your insistence that the issue was not with the core, that got me on the right track, but what has helped me the most was the link provided by rkivisto https://support.cloudbees.com/hc/en-us/articles/360058194871 this link had a script on the buttom of the page that identified exactly all of the incompatible plugins.

Once I went to https://ourjenkins.com/script and ran it. It identified the following:
Result
------------------------- Legend -------------------------
obsolete: The plugin should not be used anymore. No test was performed at all.
incompatible: The plugin is not compatible and should be removed
------------------------- List of issues -------------------------
[WARNING] 'Checkstyle Plug-in' status is incompatible
[WARNING] 'Publish Over SSH' status is incompatible but there is new version with a fix 1.21
[WARNING] 'Static Analysis Utilities' status is obsolete
[WARNING] 'PMD Plug-in' status is incompatible
[WARNING] 'DRY Plug-in' status is obsolete
-------------------------
 
Disabling 'Publish Over SSH plug in solved the issue. 
 
Thanks again for everything guys.
Regards,
Harry
 

hkyupelyan pull requests are certainly welcomed.

Hi hkyupelyan

> The issue I have with this entire approach is that since Jenkins made this effort to convert al of html into divs, Jenkins should release a tool / plugin to detect and identify all of the plugins that are incompatible with html to jenkins div cutover.

In addition of the script provided in the KB from CloudBees these problems are also detected by the Jenkins Health Advisor by CloudBees plugin/service which is free for all Jenkins users: https://plugins.jenkins.io/cloudbees-jenkins-advisor/ The service is identified all impacted plugins even before you upgrade.

I understand you would prefer to have something provided by the community and not by a vendor but there are some limit of times/efforts in any open-source community which cannot be easily solved. As said markewaite, PRs and contributions are all welcomed.

Cheers