Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70286

Update jobcopy builder to require a newer minimum Jenkins version

      It seems that JobCopy-Builder-Plugin has an implied dependency on WMI Windows Agents that is deprecated. When the second will be removed in the future, the first one could stop working. The implied dependency means that the user of the plugin needs to either remove the jobcopy builder plugin or risk surprises with the removal of the WMI Windows Agents plugin.

      Similar to JENKINS-70148

      The jobcopy builder plugin needs a new release that requires a more modern Jenkins version. See the "Improve a Plugin" tutorial for instructions to make that change.

          [JENKINS-70286] Update jobcopy builder to require a newer minimum Jenkins version

          Mark Waite added a comment -

          See the tracking sheet that I'm maintaining for the plugins with implied dependencies on WMI Windows Agents

          Mark Waite added a comment - See the tracking sheet that I'm maintaining for the plugins with implied dependencies on WMI Windows Agents

          ikedam added a comment -

          There looks many (351!) plugins with the same issue.
          I expect more information or some guideline from the community.
          Followings are notes for the time to broadcast this issue to those affected plugins:

          > When the second will be removed in the future, the first one could stop working.

          I believe it actually doesn't stop working.
          "Implied dependency" doesn't mean the plugin actually depend on that plugin. Developers might not know what "implied dependency" means and I expect more explanations about that.

          > Similar to https://issues.jenkins.io/browse/JENKINS-70148

          This ticket has no comments and I couldn't get how the issue was resolved. An example solution would help plugin developers.

          I don't know about WMI agent at all, and I don't know why it is deprecated. Plugin developers can't know whether their plugins depend on that plugin without what is WMI agent.
          Other plugins have been split from Jenkins core (like matrix-project), and I wonder why only WMI agent gets an issue.
          I want more contexts about WMI agent plugin.

          ikedam added a comment - There looks many (351!) plugins with the same issue. I expect more information or some guideline from the community. Followings are notes for the time to broadcast this issue to those affected plugins: > When the second will be removed in the future, the first one could stop working. I believe it actually doesn't stop working. "Implied dependency" doesn't mean the plugin actually depend on that plugin. Developers might not know what "implied dependency" means and I expect more explanations about that. > Similar to https://issues.jenkins.io/browse/JENKINS-70148 This ticket has no comments and I couldn't get how the issue was resolved. An example solution would help plugin developers. I don't know about WMI agent at all, and I don't know why it is deprecated. Plugin developers can't know whether their plugins depend on that plugin without what is WMI agent. Other plugins have been split from Jenkins core (like matrix-project), and I wonder why only WMI agent gets an issue. I want more contexts about WMI agent plugin.

          Mark Waite added a comment - - edited

          Thanks for your response ikedam and thanks for the prompting questions. I'll follow the pattern that Basil and others have used and will create a Jira epic to capture the issues for other plugins. That will allow multiple Jira issues to be grouped in a single page with the details about implied dependencies in that single page.

          What is an implied dependency?

          Implied dependencies are described on the plugins.jenkins.io site in the "What's this?" text as:

          Features are sometimes detached (or split off) from Jenkins core and moved into a plugin. Many plugins, like Subversion or JUnit, started as features of Jenkins core.

          Plugins that depend on a Jenkins core version before such a plugin was detached from core may or may not actually use any of its features. To ensure that plugins don't break whenever functionality they depend on is detached from Jenkins core, it is considered to have a dependency on the detached plugin if it declares a dependency on a version of Jenkins core before the split. Since that dependency to the detached plugin is not explicitly specified, it is implied.

          Plugins that don't regularly update which Jenkins core version they depend on will accumulate implied dependencies over time.

          In most cases, the plugin that has the implied dependency will not stop working when the WMI Windows Agent plugin is removed. However, the user cannot be confident of that until they've removed the WMI Windows Agent plugin and confirmed that their system is still operating as expected.

          Why is WMI Windows Agents plugin deprecated?

          The reason for the deprecation of the WMI Windows Agents plugin is included on the plugin page where it says:

          This plugin is deprecated. SSH is now a very viable, secure and robust solution for connecting to Windows based agents using native Windows binaries for OpenSSH Server or another method such as cygwin. There is also the Windows Cloud plugin for Jenkins which uses WinRM, a more modern remote management solution.

          The method for connecting agents to the controller in this plugin, which is based on DCOM, has several pitfalls and issues and can be brittle. The SSH and other solutions can unify the method for connecting to all agents (Windows, Linux, macOS, etc.) in your infrastructure. It is highly recommended that you migrate to one of these other methods sooner rather than later.

          Microsoft is tightening security on DCOM based on a CVE. Initial OS updates will require a registry change to enable the current security level, then in May of 2023 they will not have a way to override the secure behavior. The library used in this plugin was last released in ~2010 and does not have an active development team. Jenkins developers have decided to deprecate this plugin rather than try and maintain the library on our own.

          Why does the implied dependency exist?

          An implied dependency exists because Jenkins core does not know if the dependent plugin requires functionality that was moved from Jenkins core to the WMI Windows Agent plugin when the WMI Windows Agent plugin was split from core. The WMI Windows Agent plugin was split from Jenkins core in release 1.547. Plugins that declare a dependency on a version of Jenkins core before the split are given the implied dependency by Jenkins core. It is "implied" because it is not directly declared in the plugin and it is a dependency because Jenkins core does not know if the API's that were in Jenkins core before the split of the plugin are required or not.

          How can the implied dependency be removed?

          The implied dependency can be removed by releasing a new version of the plugin that depends on a newer minimum Jenkins core than Jenkins 1.547. The "Improve a plugin" tutorial provides steps that can assist plugin developers as they configure the plugin to depend on a newer minimum Jenkins core.

          Mark Waite added a comment - - edited Thanks for your response ikedam and thanks for the prompting questions. I'll follow the pattern that Basil and others have used and will create a Jira epic to capture the issues for other plugins. That will allow multiple Jira issues to be grouped in a single page with the details about implied dependencies in that single page. What is an implied dependency? Implied dependencies are described on the plugins.jenkins.io site in the "What's this?" text as: Features are sometimes detached (or split off) from Jenkins core and moved into a plugin. Many plugins, like Subversion or JUnit, started as features of Jenkins core. Plugins that depend on a Jenkins core version before such a plugin was detached from core may or may not actually use any of its features. To ensure that plugins don't break whenever functionality they depend on is detached from Jenkins core, it is considered to have a dependency on the detached plugin if it declares a dependency on a version of Jenkins core before the split. Since that dependency to the detached plugin is not explicitly specified, it is implied. Plugins that don't regularly update which Jenkins core version they depend on will accumulate implied dependencies over time. In most cases, the plugin that has the implied dependency will not stop working when the WMI Windows Agent plugin is removed. However, the user cannot be confident of that until they've removed the WMI Windows Agent plugin and confirmed that their system is still operating as expected. Why is WMI Windows Agents plugin deprecated? The reason for the deprecation of the WMI Windows Agents plugin is included on the plugin page where it says: This plugin is deprecated. SSH is now a very viable, secure and robust solution for connecting to Windows based agents using native Windows binaries for OpenSSH Server or another method such as cygwin. There is also the Windows Cloud plugin for Jenkins which uses WinRM, a more modern remote management solution. The method for connecting agents to the controller in this plugin, which is based on DCOM, has several pitfalls and issues and can be brittle. The SSH and other solutions can unify the method for connecting to all agents (Windows, Linux, macOS, etc.) in your infrastructure. It is highly recommended that you migrate to one of these other methods sooner rather than later. Microsoft is tightening security on DCOM based on a CVE. Initial OS updates will require a registry change to enable the current security level, then in May of 2023 they will not have a way to override the secure behavior. The library used in this plugin was last released in ~2010 and does not have an active development team. Jenkins developers have decided to deprecate this plugin rather than try and maintain the library on our own. Why does the implied dependency exist? An implied dependency exists because Jenkins core does not know if the dependent plugin requires functionality that was moved from Jenkins core to the WMI Windows Agent plugin when the WMI Windows Agent plugin was split from core. The WMI Windows Agent plugin was split from Jenkins core in release 1.547 . Plugins that declare a dependency on a version of Jenkins core before the split are given the implied dependency by Jenkins core. It is "implied" because it is not directly declared in the plugin and it is a dependency because Jenkins core does not know if the API's that were in Jenkins core before the split of the plugin are required or not. How can the implied dependency be removed? The implied dependency can be removed by releasing a new version of the plugin that depends on a newer minimum Jenkins core than Jenkins 1.547. The "Improve a plugin" tutorial provides steps that can assist plugin developers as they configure the plugin to depend on a newer minimum Jenkins core .

          ikedam added a comment -

          Released jobcopy-builder-plugin-1.5.0 targeting Jenkins 2.346.3.

          ikedam added a comment - Released jobcopy-builder-plugin-1.5.0 targeting Jenkins 2.346.3.

          hugo added a comment -
          Jobcopy Builder Failure -
          java.io.FileNotFoundException: https://get.jenkins.io/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1920) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1520) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250) at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1274) Caused: java.io.IOException: Failed to load https://updates.jenkins.io/download/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi to /a2b/jenkins/jenkins-data/plugins/jobcopy-builder.jpi.tmp at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1285) Caused: java.io.IOException: Failed to download from https://updates.jenkins.io/download/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi (redirected to: https://get.jenkins.io/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi) at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1319) at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1876) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:2188) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1850) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:121) at java.base/java.lang.Thread.run(Thread.java:829) 

           

          hugo added a comment - Jobcopy Builder Failure - java.io.FileNotFoundException: https: //get.jenkins.io/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1920) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1520) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250) at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1274) Caused: java.io.IOException: Failed to load https://updates.jenkins.io/download/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi to /a2b/jenkins/jenkins-data/plugins/jobcopy-builder.jpi.tmp at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1285) Caused: java.io.IOException: Failed to download from https://updates.jenkins.io/download/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi (redirected to: https://get.jenkins.io/plugins/jobcopy-builder/1.5.0/jobcopy-builder.hpi) at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1319) at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1876) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:2188) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1850) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:121) at java.base/java.lang. Thread .run( Thread .java:829)  

          Mark Waite added a comment - - edited

          I see similar results as supertwinky.

          The GitHub repository and the plugins site show that 1.5.0 is released. The 1.5.0 plugin release is available from the artifact repository.

          The update site reports a URL of https://updates.jenkins.io/latest/jobcopy-builder.hpi but when I try to check the mirrors at https://updates.jenkins.io/latest/jobcopy-builder.hpi?mirrorlist , it reports not found.

          I think that means that the process that detects new plugin releases and makes them available through the update center has not done its job in this case. That is surprising since the httpcomponents plugin update that was released after jobcopy-builder 1.5.0 is available from the update center. We may need help from the infra team to understand this failure.

          I've uploaded the 1.5.0 release as an attachment in case someone needs to install it with the plugin manager "advanced" page. See jobcopy-builder.hpi

          Opened the Jenkins infrastructure help ticket.

          Mark Waite added a comment - - edited I see similar results as supertwinky . The GitHub repository and the plugins site show that 1.5.0 is released. The 1.5.0 plugin release is available from the artifact repository. The update site reports a URL of https://updates.jenkins.io/latest/jobcopy-builder.hpi but when I try to check the mirrors at https://updates.jenkins.io/latest/jobcopy-builder.hpi?mirrorlist , it reports not found . I think that means that the process that detects new plugin releases and makes them available through the update center has not done its job in this case. That is surprising since the httpcomponents plugin update that was released after jobcopy-builder 1.5.0 is available from the update center. We may need help from the infra team to understand this failure. I've uploaded the 1.5.0 release as an attachment in case someone needs to install it with the plugin manager "advanced" page. See jobcopy-builder.hpi Opened the Jenkins infrastructure help ticket .

            ikedam ikedam
            stebertoz Stefano
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: