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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Labels:
    • Environment:
    • Similar Issues:
    • Released As:
      Jenkins 2.145 and Jenkins 2.138.3

      Description

      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.

       

        Attachments

          Activity

          Hide
          jraezrus Javier Raez added a comment -

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

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

          Is it only GitHub or any provider?

          Show
          rsandell rsandell added a comment - Is it only GitHub or any provider?
          Hide
          jstripsky 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. 

          Show
          jstripsky 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. 
          Hide
          dnusbaum 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).

          Show
          dnusbaum 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).
          Hide
          dnusbaum 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.

          Show
          dnusbaum 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.
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          The core's part was released in Jenkins 2.145

          Show
          oleg_nenashev Oleg Nenashev added a comment - The core's part was released in Jenkins 2.145
          Hide
          dnusbaum Devin Nusbaum added a comment -

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

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

            People

            • Assignee:
              dnusbaum Devin Nusbaum
              Reporter:
              jraezrus Javier Raez
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: