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

SCM Sync unmaintained

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Looking at the GitHub repo, it has 30 open issues and 11 open PRs, including a request from March to cut a new release. The last commit was in 2017, and before that there were only commits in 2016 and prior. What can be done about rescuing this excellent plugin? There was a lot of interest shown here, but it didn't get anywhere.

      Eventually it occurred to me to open the issue in JIRA, which seems to be more "Jenkinsy" than GitHub.

        Attachments

          Activity

          Hide
          ctataryn Craig Tataryn added a comment - - edited

          I'd definitely like to help. What I don't think helps is this wiki entry:

          https://wiki.jenkins.io/pages/diffpagesbyversion.action?pageId=46336078&selectedPageVersions=105&selectedPageVersions=106

          Craig Rodrigues I have changed the "Deprecation" terminology of the note in favour of simply restating it as being "Alternatives" to the SCM Sync Plugin:

          https://wiki.jenkins.io/pages/diffpagesbyversion.action?pageId=46336078&selectedPageVersions=107&selectedPageVersions=106

          Show
          ctataryn Craig Tataryn added a comment - - edited I'd definitely like to help. What I don't think helps is this wiki entry: https://wiki.jenkins.io/pages/diffpagesbyversion.action?pageId=46336078&selectedPageVersions=105&selectedPageVersions=106 Craig Rodrigues I have changed the "Deprecation" terminology of the note in favour of simply restating it as being "Alternatives" to the SCM Sync Plugin: https://wiki.jenkins.io/pages/diffpagesbyversion.action?pageId=46336078&selectedPageVersions=107&selectedPageVersions=106
          Hide
          rodrigc Craig Rodrigues added a comment -

          Craig Tataryn thanks for taking an interest in this plugin, but please revert your changes on the wiki.

          This plugin is deprecated, and the wiki should reflect that.

           

          The plugin was originally written at a time when the XML config files used by Jenkins could not easily

          be backed up in an SCM.  The unfortunate thing is that this plugin hooks into some low-level entrypoints

          in Jenkins to back up the config to an SCM, and gets it really, really wrong in many cases.  This can be

          seen by the many problems and bug reports over the years.

           

          The direction of Jenkins is Pipeline and Configuration as Code, so users are better off migrating to those

          technologies, rather than supporting deprecated things like SCM Configuration Plugin, which is broken in many areas.

          Show
          rodrigc Craig Rodrigues added a comment - Craig Tataryn thanks for taking an interest in this plugin, but please revert your changes on the wiki. This plugin is deprecated, and the wiki should reflect that.   The plugin was originally written at a time when the XML config files used by Jenkins could not easily be backed up in an SCM.  The unfortunate thing is that this plugin hooks into some low-level entrypoints in Jenkins to back up the config to an SCM, and gets it really, really wrong in many cases.  This can be seen by the many problems and bug reports over the years.   The direction of Jenkins is Pipeline and Configuration as Code, so users are better off migrating to those technologies, rather than supporting deprecated things like SCM Configuration Plugin, which is broken in many areas.
          Hide
          antgel Antony Gelberg added a comment -

          Craig Rodrigues See the discussion at https://github.com/jenkinsci/scm-sync-configuration-plugin/issues/54 - is it really so cut and dried? I didn't know about configuration as code, and I'm reading https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md. Is configuration as code a relatively new thing? Can that and pipeline definitely cover all that SCM could? If so, I'll close this ticket and look at migrating.

          Show
          antgel Antony Gelberg added a comment - Craig Rodrigues See the discussion at https://github.com/jenkinsci/scm-sync-configuration-plugin/issues/54 - is it really so cut and dried? I didn't know about configuration as code, and I'm reading https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md . Is configuration as code a relatively new thing? Can that and pipeline definitely cover all that SCM could? If so, I'll close this ticket and look at migrating.
          Hide
          ctataryn Craig Tataryn added a comment -

          Craig Rodrigues Here's why I feel this plugin is still important:

          I have a whole ecosystem of "legacy" jobs (i.e. non-pipeline). They use a wide range of plugins, and special parameter types that I've cultivated over the years. Here's what I typically see when I try to use the "Convert to Pipeline" feature:

           

          // Unable to convert a build step referring to "hudson.plugins.copyartifact.CopyArtifact". Please verify and convert manually if required.
          // Unable to convert a build step referring to "jenkins.plugins.publish__over__ssh.BapSshBuilderPlugin". Please verify and convert manually if required.
          // Unable to convert a build step referring to "jenkins.plugins.publish__over__ssh.BapSshBuilderPlugin". Please verify and convert manually if required.
          // Unable to convert a build step referring to "org.jenkinsci.plugins.conditionalbuildstep.singlestep.SingleConditionalBuilder". Please verify and convert manually if required.
          // Unable to convert a build step referring to "org.jenkinsci.plugins.conditionalbuildstep.singlestep.SingleConditionalBuilder". Please verify and convert manually if required.
          // Unable to convert a build step referring to "org.jenkinsci.plugins.conditionalbuildstep.ConditionalBuilder". Please verify and convert manually if required.
          // Unable to convert a build step referring to "org.jvnet.hudson.plugins.SSHBuilder". Please verify and convert manually if required.
          // Unable to convert a build step referring to "org.jvnet.hudson.plugins.SSHBuilder". Please verify and convert manually if required. 
          

           

          The Jenkins documentation is not very clear on what to do in this situation. 

          To keep up the the Jones' what I typically do is create an "umbrella" Pipeline script that takes care of orchestration between my legacy jobs.  I am perfectly content with leaving those legacy jobs as-is instead of trying to "fix" what ain't broken.  The only modification I'll make to my legacy jobs is strip them of their responsibility for kicking off downstream jobs. I instead let my orchestrating pipeline script handle that.

          I'll bet if you ask around, you'll find that my situation isn't at all unique in the community.

          Ultimately, stripping out the bells and whistles of per-change commit messages, the plugin is really just asking git (in my case) to commit/push using a .gitignore similar to:

           

          # Ignore Everything
          *
          #######################
          # Except these files...
          #######################
          !.gitignore
          # Jenkins main config and job configs
          !config.xml
          # deployment keys for accessing bitbucket
          !sshkeys/*
          # plugin configs
          !hudson*.xml
          #Even if those files are in sub directories
          !*/
          #######################
          

          I think this plugin is still important, and it should live on in some fashion. It may have to drop some features, but at least it'll still give people a bit of security knowing that if they mistakenly messed up a job, they can easily go to SCM and lookup the previous version of their job in an effort to restore it.

           

           

           

          Show
          ctataryn Craig Tataryn added a comment - Craig Rodrigues Here's why I feel this plugin is still important: I have a whole ecosystem of "legacy" jobs (i.e. non-pipeline). They use a wide range of plugins, and special parameter types that I've cultivated over the years. Here's what I typically see when I try to use the "Convert to Pipeline" feature:   // Unable to convert a build step referring to "hudson.plugins.copyartifact.CopyArtifact" . Please verify and convert manually if required. // Unable to convert a build step referring to "jenkins.plugins.publish__over__ssh.BapSshBuilderPlugin" . Please verify and convert manually if required. // Unable to convert a build step referring to "jenkins.plugins.publish__over__ssh.BapSshBuilderPlugin" . Please verify and convert manually if required. // Unable to convert a build step referring to "org.jenkinsci.plugins.conditionalbuildstep.singlestep.SingleConditionalBuilder" . Please verify and convert manually if required. // Unable to convert a build step referring to "org.jenkinsci.plugins.conditionalbuildstep.singlestep.SingleConditionalBuilder" . Please verify and convert manually if required. // Unable to convert a build step referring to "org.jenkinsci.plugins.conditionalbuildstep.ConditionalBuilder" . Please verify and convert manually if required. // Unable to convert a build step referring to "org.jvnet.hudson.plugins.SSHBuilder" . Please verify and convert manually if required. // Unable to convert a build step referring to "org.jvnet.hudson.plugins.SSHBuilder" . Please verify and convert manually if required.   The Jenkins documentation is not very clear on what to do in this situation.  To keep up the the Jones' what I typically do is create an "umbrella" Pipeline script that takes care of orchestration between my legacy jobs.  I am perfectly content with leaving those legacy jobs as-is instead of trying to "fix" what ain't broken.  The only modification I'll make to my legacy jobs is strip them of their responsibility for kicking off downstream jobs. I instead let my orchestrating pipeline script handle that. I'll bet if you ask around, you'll find that my situation isn't at all unique in the community. Ultimately, stripping out the bells and whistles of per-change commit messages, the plugin is really just asking git (in my case) to commit/push using a .gitignore  similar to:   # Ignore Everything * ####################### # Except these files... ####################### !.gitignore # Jenkins main config and job configs !config.xml # deployment keys for accessing bitbucket !sshkeys/* # plugin configs !hudson*.xml #Even if those files are in sub directories !*/ ####################### I think this plugin is still important, and it should live on in some fashion. It may have to drop some features, but at least it'll still give people a bit of security knowing that if they mistakenly messed up a job, they can easily go to SCM and lookup the previous version of their job in an effort to restore it.      
          Hide
          rodrigc Craig Rodrigues added a comment -

          Antony Gelberg The Jenkins core devs are pushing pipeline heavily, so going in that direction is definitely the way to go for jobs.  I understand that it is painful when you have a pile of "legacy" jobs, but going in the direction of Pipeline for jobs is better than dealing with plugins that try to band-aid over functionality lacking in earlier versions of Jenkins.

          For Configuration As Code, that stuff is newer, but it has received a lot of support via the Jenkins Enhancement Process (JEP), and seems to be the future of how the configuration of Jenkins itself can be handled in a way that can be more "devops" and "SCM" friendly.  I would suggest that you try to work with the developers of that via the Gitter channel: https://jenkins.io/chat/

          SCM Sync was good for its time, but it is in de-orbit and burn mode now, so I would recommend going with the direction of "modern" Jenkins for this stuff.

          Show
          rodrigc Craig Rodrigues added a comment - Antony Gelberg The Jenkins core devs are pushing pipeline heavily, so going in that direction is definitely the way to go for jobs.  I understand that it is painful when you have a pile of "legacy" jobs, but going in the direction of Pipeline for jobs is better than dealing with plugins that try to band-aid over functionality lacking in earlier versions of Jenkins. For Configuration As Code, that stuff is newer, but it has received a lot of support via the Jenkins Enhancement Process (JEP), and seems to be the future of how the configuration of Jenkins itself can be handled in a way that can be more "devops" and "SCM" friendly.  I would suggest that you try to work with the developers of that via the Gitter channel: https://jenkins.io/chat/ SCM Sync was good for its time, but it is in de-orbit and burn mode now, so I would recommend going with the direction of "modern" Jenkins for this stuff.
          Hide
          jonl_percsol Jonathon Lamon added a comment -

          There's a matter of time problem here.  Time in life is limited.  The solutions to fix the problems with the plugin probably take less time than it does for the people using the plugin to migrate the jenkins jobs that work to a new configuration solution that is being pushed as the solution without our asking or consent that is buggy in of itself and not applicable to every situation just yet.  So, I understand that while this might be deprecated, there is no need to allow it to break the system in the meantime for the people that rely upon it.  If the core devs don't want to deal with the issue, then at least allow someone from the community what they can do to help maintain the plugin until such a time as it can stop being relied upon or at least stop being broken.  

          Show
          jonl_percsol Jonathon Lamon added a comment - There's a matter of time problem here.  Time in life is limited.  The solutions to fix the problems with the plugin probably take less time than it does for the people using the plugin to migrate the jenkins jobs that work to a new configuration solution that is being pushed as the solution without our asking or consent that is buggy in of itself and not applicable to every situation just yet.  So, I understand that while this might be deprecated, there is no need to allow it to break the system in the meantime for the people that rely upon it.  If the core devs don't want to deal with the issue, then at least allow someone from the community what they can do to help maintain the plugin until such a time as it can stop being relied upon or at least stop being broken.  

            People

            • Assignee:
              Unassigned
              Reporter:
              antgel Antony Gelberg
            • Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: