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

When adding a new Global Pipeline Libraries the previous repository information is lost

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • Jenkins 2.145 and Jenkins 2.138.3

      When adding a new Global Pipeline Libraries and save it the previous repository information is lost. Only have the last one created.

      I have attached the snapshot of the process and also a javascript error from the console.

       

          [JENKINS-48516] When adding a new Global Pipeline Libraries the previous repository information is lost

          Javier Raez added a comment -

          The problem is related to the UI only. The repositories are saved correctly but only shows the last one

          Javier Raez added a comment - The problem is related to the UI only. The repositories are saved correctly but only shows the last one

          rsandell added a comment -

          Is it only GitHub or any provider?

          rsandell added a comment - Is it only GitHub or any provider?

          Jim Stripsky added a comment - - edited

          I have the same issue loading libraries with GIT in TeamForge. 

          The issue exists using Chrome on Windows or Mac or Safari on Mac. 

          Jim Stripsky added a comment - - edited I have the same issue loading libraries with GIT in TeamForge.  The issue exists using Chrome on Windows or Mac or Safari on Mac. 

          Devin Nusbaum added a comment -

          I think part of the issue here might be that this code is not creating totally unique prefixes for nested groups of radio buttons. Specifically, the Modern/Legacy SCM radio buttons and the inner radio buttons for each SCM type all have the same prefix for a single library, which seems wrong.

          If I use ${h.generateId()} to uniquify the varNames}}s for all uses of {{f:repeatableBlock in workflow-cps-global-lib, then the issue appears to go away for modern SCMs (not sure about Legacy SCMs, it seemed like they weren't fixed, but that might just have been inconsistent testing).

          Devin Nusbaum added a comment - I think part of the issue here might be that this code is not creating totally unique prefixes for nested groups of radio buttons. Specifically, the Modern/Legacy SCM radio buttons and the inner radio buttons for each SCM type all have the same prefix for a single library, which seems wrong. If I use ${h.generateId() } to uniquify the varNames}}s for all uses of {{f:repeatableBlock in workflow-cps-global-lib, then the issue appears to go away for modern SCMs (not sure about Legacy SCMs, it seemed like they weren't fixed, but that might just have been inconsistent testing).

          Devin Nusbaum added a comment -

          It looks like the root cause was that radioBlock.js set the initial visibility for each radio button group using names to distinguish groups before repeatable.js uniquified the names. I've submitted a PR to workflow-cps-global-lib to work around the issue, and a PR to Jenkins core to fix the root cause.

          Devin Nusbaum added a comment - It looks like the root cause was that radioBlock.js set the initial visibility for each radio button group using names to distinguish groups before repeatable.js uniquified the names. I've submitted a PR to workflow-cps-global-lib to work around the issue, and a PR to Jenkins core to fix the root cause.

          Oleg Nenashev added a comment -

          The core's part was released in Jenkins 2.145

          Oleg Nenashev added a comment - The core's part was released in Jenkins 2.145

          Devin Nusbaum added a comment -

          Given that the fix in Core was backported to the 2.138 LTS line, I am closing the issue.

          Devin Nusbaum added a comment - Given that the fix in Core was backported to the 2.138 LTS line, I am closing the issue.

          Jean-Pierre Fouche added a comment - - edited

          Shared Libraries Plugin still broken? 

          This seems to be happening in 2.303.2 with Chrome Version 95.0.4638.69 (Official Build) (x86_64)

          It does not happen on Firefox 93.0 64 bit.

          The plugin appears to scan all repositories (you can see this on-screen) and remains on the last one scanned.  The UI is broken, but the Shared Libraries config is correct under the hood, as evidenced by my jobs running with success.  Thanks to KS for identifying the issue immediately.

           

          Jean-Pierre Fouche added a comment - - edited Shared Libraries Plugin still broken?  This seems to be happening in 2.303.2 with Chrome Version 95.0.4638.69 (Official Build) (x86_64) It does not happen on Firefox 93.0 64 bit. The plugin appears to scan all repositories (you can see this on-screen) and remains on the last one scanned.  The UI is broken, but the Shared Libraries config is correct under the hood, as evidenced by my jobs running with success.  Thanks to KS for identifying the issue immediately.  

            dnusbaum Devin Nusbaum
            jraezrus Javier Raez
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: