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

Split changelog by repository when using the multiple SCM plugin

XMLWordPrintable

      In my company we use the SCM plugin a lot for aggregating various components located in different repos, and we would find our changelogs much more useful if they would be split by repository in which the changes happened.

      At the moment they are split by the type of SCM (git, SVN ,etc.) but that's not useful if you have only multiple git repos and no SVN repo, for example. We just see a list of all the changes that happened across all those git repos which is not really useful.

          [JENKINS-31934] Split changelog by repository when using the multiple SCM plugin

          Jacob Keller added a comment -

          Pull Request https://github.com/jenkinsci/git-plugin/pull/374

          Jacob Keller added a comment - Pull Request https://github.com/jenkinsci/git-plugin/pull/374

          Craig Rodrigues added a comment -

          Suggest that you migrate to Pipeline plugin, which offers a supported way of checking out from multiple scms
          https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin

          Craig Rodrigues added a comment - Suggest that you migrate to Pipeline plugin, which offers a supported way of checking out from multiple scms https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Jacob Keller
          Path:
          src/main/java/hudson/plugins/git/extensions/impl/SubmoduleOption.java
          src/test/java/hudson/plugins/git/extensions/impl/SubmoduleOptionTest.java
          http://jenkins-ci.org/commit/git-plugin/d74750819e5a2ed5397763954d0a32d22d062f6d
          Log:
          JENKINS-31934 throw IOException around submodule update failures

          Updating the submodule can fail in a similar manner to git checkout of
          the parent project. If we simply throw the GitException, then the
          generic retry loop will not kick in.

          For now, the only exceptions we'll catch is the GitException which
          should be generated if the launchCommand fails.

          Without this change, intermittent failures when attempting to pull
          submodule data from a git remote will not properly allow the retry loop
          to kick in.

          Add a new test case to verify that we actually do throw the IOException.
          Because this exception case is likely due to an intermittent error,
          we'll use mocks to setup a case where we always throw the exception.

          Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jacob Keller Path: src/main/java/hudson/plugins/git/extensions/impl/SubmoduleOption.java src/test/java/hudson/plugins/git/extensions/impl/SubmoduleOptionTest.java http://jenkins-ci.org/commit/git-plugin/d74750819e5a2ed5397763954d0a32d22d062f6d Log: JENKINS-31934 throw IOException around submodule update failures Updating the submodule can fail in a similar manner to git checkout of the parent project. If we simply throw the GitException, then the generic retry loop will not kick in. For now, the only exceptions we'll catch is the GitException which should be generated if the launchCommand fails. Without this change, intermittent failures when attempting to pull submodule data from a git remote will not properly allow the retry loop to kick in. Add a new test case to verify that we actually do throw the IOException. Because this exception case is likely due to an intermittent error, we'll use mocks to setup a case where we always throw the exception. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

            kbell Kevin Bell
            alien_ Cristian Magherusan-Stanciu
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: