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

UpdateCenter fails to find newer plugin versions from additional sites

      It seems that current implementation of UpdateCenter fails to find any plugins that exists in multiple repositories (sites) and is using only the version found on the first repository.

      <sites>
      <site>
      <id>default</id>
      <url>http://updates.jenkins-ci.org/stable/update-center.json</url>
      </site>
      <site>
      <id>custom</id>
      <url>http://example.com/update-center/jenkins/update-center.json</url>
      </site>
      </sites>
      

      If default site includes foobar-1.0 and custom site includes foobar-1.2, Jenkins will find only foobar-1.0.

      This is critical because due to the lots of dependencies between Jenkins plugins it makes almost impossible to work with multiple sites. At current stage multiple sites works only if you do not have overlapping plugins.

       

          [JENKINS-45235] UpdateCenter fails to find newer plugin versions from additional sites

          Daniel Beck added a comment -

          The code looks like installing 1.0 and then updating it to 1.2 ("Updates" tab) should be a possible workaround, but will require restart.

          Also, from looking at the code, it seems like the secondary update center could define categories not used on the Jenkins update site, and the plugin will show up there due to category based grouping on Available tab. Also a workaround, but still.

          Daniel Beck added a comment - The code looks like installing 1.0 and then updating it to 1.2 ("Updates" tab) should be a possible workaround, but will require restart. Also, from looking at the code, it seems like the secondary update center could define categories not used on the Jenkins update site, and the plugin will show up there due to category based grouping on Available tab. Also a workaround, but still.

          Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

          Stephen Connolly added a comment - Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

            Unassigned Unassigned
            ssbarnea Sorin Sbarnea
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: