• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • Jenkins: 1.653
      git-client: 1.19.6
      git: 2.4.3

      Consider the following excerpt from a job's config.xml:

      <scm class="hudson.plugins.git.GitSCM" plugin="git@2.4.3">
      <configVersion>2</configVersion>
      <userRemoteConfigs>
      <hudson.plugins.git.UserRemoteConfig>
      <name>gitlab</name>
      <url>[URL GOES HERE]</url>
      <credentialsId>[CREDENTIAL]</credentialsId>
      </hudson.plugins.git.UserRemoteConfig>
      </userRemoteConfigs>
      <branches>
      <hudson.plugins.git.BranchSpec>
      <name>*/nt-*</name>
      </hudson.plugins.git.BranchSpec>
      <hudson.plugins.git.BranchSpec>
      <name>**/master</name>
      </hudson.plugins.git.BranchSpec>
      <hudson.plugins.git.BranchSpec>
      <name>**/bleeding</name>
      </hudson.plugins.git.BranchSpec>
      [OTHER BRANCH DESIGNATIONS]
      </branches>
      <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
      <submoduleCfg class="list"/>
      <extensions>
      <hudson.plugins.git.extensions.impl.BuildChooserSetting>
      <buildChooser class="hudson.plugins.git.util.InverseBuildChooser"/>
      </hudson.plugins.git.extensions.impl.BuildChooserSetting>
      <hudson.plugins.git.extensions.impl.BuildChooserSetting>
      <buildChooser class="hudson.plugins.git.util.AncestryBuildChooser">
      <maximumAgeInDays>14</maximumAgeInDays>
      <ancestorCommitSha1></ancestorCommitSha1>
      </buildChooser>
      </hudson.plugins.git.extensions.impl.BuildChooserSetting>
      <hudson.plugins.git.extensions.impl.MessageExclusion>
      <excludedMessage>[REGEX HERE]</excludedMessage>
      </hudson.plugins.git.extensions.impl.MessageExclusion>
      </extensions>
      </scm>

      After reloading configurations from disk, the appropriate settings are displayed in the Additional Behvaiors area of the job's git configuration. However, if I change any of the settings and save the job, the <extensions> element is removed from the XML entirely, and the related configurations are annihilated.

      Additionally, and this may require a new issue, out of these behaviors, only the first one is used: if I move the AncestryBuildChooser to the top of the element, only the commits younger than 14 days are built, but the InverseBuildChooser setting is ignored. If left in the current configuration, only the InverseBuildChooser setting is used, but Jenkins starts builds rapidly to catch up with the untested old commits, the majority of which will fail the build due to various changes over the years.

          [JENKINS-33695] Git plugin writing out incorrect settings

          Thanks for the quick reaction, Mark!

          Just to clarify, will I be able to retain multiple build chooser behaviors, or should I start looking into another way of achieving the same (or similar functionality)?

          Zalan Meggyesi added a comment - Thanks for the quick reaction, Mark! Just to clarify, will I be able to retain multiple build chooser behaviors, or should I start looking into another way of achieving the same (or similar functionality)?

          Mark Waite added a comment -

          You'll be able to retain multiple build chooser settings. I did not intend to remove a capability from the plugin that was already there. I try my very best to not lose functionality from the plugin.

          Unfortunately, in this case I had no automated test to check for that functionality, and I was not aware of the functionality until your bug report showed that I had inadvertently removed it.

          Mark Waite added a comment - You'll be able to retain multiple build chooser settings. I did not intend to remove a capability from the plugin that was already there. I try my very best to not lose functionality from the plugin. Unfortunately, in this case I had no automated test to check for that functionality, and I was not aware of the functionality until your bug report showed that I had inadvertently removed it.

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/7f21ab8da120d285b81a07a33fbe2ad54965fa9d
          Log:
          Fix JENKINS-33695 by reverting "Fix GitSCM findbugs serialization warnings"

          This reverts commit bb6f6866c0f4966ab5ee4487440e4fc0009d22ed and fixes
          JENKINS-33695. The serialization of extensions is critical to preserving
          the settings when saving the job.

          Most embarrassing that my interactive testing prior to release of git
          plugin 2.4.3 did not detect the problem.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/7f21ab8da120d285b81a07a33fbe2ad54965fa9d Log: Fix JENKINS-33695 by reverting "Fix GitSCM findbugs serialization warnings" This reverts commit bb6f6866c0f4966ab5ee4487440e4fc0009d22ed and fixes JENKINS-33695 . The serialization of extensions is critical to preserving the settings when saving the job. Most embarrassing that my interactive testing prior to release of git plugin 2.4.3 did not detect the problem.

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/test/java/hudson/plugins/git/GitSCMTest.java
          http://jenkins-ci.org/commit/git-plugin/4a9031e881c44bd0c6821d0f5a604b91c56da03a
          Log:
          Add test for JENKINS-33695 fix

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/test/java/hudson/plugins/git/GitSCMTest.java http://jenkins-ci.org/commit/git-plugin/4a9031e881c44bd0c6821d0f5a604b91c56da03a Log: Add test for JENKINS-33695 fix

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/main/java/hudson/plugins/git/util/GitUtils.java
          http://jenkins-ci.org/commit/git-plugin/20048bc98ae89a96c761dd5a2d00ed447c296784
          Log:
          Revert "Make GitUtils.git a transient field - cannot serialize it"

          This reverts commit 139020477c1e88589a0cd4a2280d6d6b8316f1fc in case a
          problem like JENKINS-33695 affects this area of the code as well.

          Compare: https://github.com/jenkinsci/git-plugin/compare/8bb7927a34b6...20048bc98ae8

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/util/GitUtils.java http://jenkins-ci.org/commit/git-plugin/20048bc98ae89a96c761dd5a2d00ed447c296784 Log: Revert "Make GitUtils.git a transient field - cannot serialize it" This reverts commit 139020477c1e88589a0cd4a2280d6d6b8316f1fc in case a problem like JENKINS-33695 affects this area of the code as well. Compare: https://github.com/jenkinsci/git-plugin/compare/8bb7927a34b6...20048bc98ae8

          Mark Waite added a comment -

          Fixed in git plugin 2.4.4, released 24 Mar 2016

          Mark Waite added a comment - Fixed in git plugin 2.4.4, released 24 Mar 2016

          Mark, I'm not sure the new version fixes the issues completely: the plugin still only considers the first child node of the <extensions> element, though both are written out when saving the config.

          Was this actually what you meant when you wrote "You'll be able to retain multiple build chooser settings."? My understanding was that as before, the plugin will only build commits that satisfy both conditions (i.e. the intersection of the matches).

          Just to make sure we're in possession of the same information, an anonymized version of the applicable XML node from my job config.xml:

          <scm class="hudson.plugins.git.GitSCM" plugin="git@2.4.4">
          	<configVersion>2</configVersion>
          	<userRemoteConfigs>
          		<hudson.plugins.git.UserRemoteConfig>
          			<name>gitlab</name>
          			<url>[URL]</url>
          			<credentialsId>[CREDENTIAL]</credentialsId>
          		</hudson.plugins.git.UserRemoteConfig>
          	</userRemoteConfigs>
          	<branches>
          		<hudson.plugins.git.BranchSpec>
          			<name>**/master</name>
          		</hudson.plugins.git.BranchSpec>
          		<hudson.plugins.git.BranchSpec>
          			<name>**/bleeding</name>
          		</hudson.plugins.git.BranchSpec>
          	</branches>
          	<doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
          	<submoduleCfg class="list"/>
          	<extensions>
          		<hudson.plugins.git.extensions.impl.BuildChooserSetting>
          			<buildChooser class="hudson.plugins.git.util.AncestryBuildChooser">
          				<maximumAgeInDays>14</maximumAgeInDays>
          				<ancestorCommitSha1/>
          			</buildChooser>
          		</hudson.plugins.git.extensions.impl.BuildChooserSetting>
          		<hudson.plugins.git.extensions.impl.BuildChooserSetting>
          			<buildChooser class="hudson.plugins.git.util.InverseBuildChooser"/>
          		</hudson.plugins.git.extensions.impl.BuildChooserSetting>
          	</extensions>
          </scm>
          

          Would this be considered a separate issue, or should this one be re-opened?

          Zalan Meggyesi added a comment - Mark, I'm not sure the new version fixes the issues completely: the plugin still only considers the first child node of the <extensions> element, though both are written out when saving the config. Was this actually what you meant when you wrote "You'll be able to retain multiple build chooser settings."? My understanding was that as before, the plugin will only build commits that satisfy both conditions (i.e. the intersection of the matches). Just to make sure we're in possession of the same information, an anonymized version of the applicable XML node from my job config.xml: <scm class= "hudson.plugins.git.GitSCM" plugin= "git@2.4.4" > <configVersion> 2 </configVersion> <userRemoteConfigs> <hudson.plugins.git.UserRemoteConfig> <name> gitlab </name> <url> [URL] </url> <credentialsId> [CREDENTIAL] </credentialsId> </hudson.plugins.git.UserRemoteConfig> </userRemoteConfigs> <branches> <hudson.plugins.git.BranchSpec> <name> **/master </name> </hudson.plugins.git.BranchSpec> <hudson.plugins.git.BranchSpec> <name> **/bleeding </name> </hudson.plugins.git.BranchSpec> </branches> <doGenerateSubmoduleConfigurations> false </doGenerateSubmoduleConfigurations> <submoduleCfg class= "list" /> <extensions> <hudson.plugins.git.extensions.impl.BuildChooserSetting> <buildChooser class= "hudson.plugins.git.util.AncestryBuildChooser" > <maximumAgeInDays> 14 </maximumAgeInDays> <ancestorCommitSha1/> </buildChooser> </hudson.plugins.git.extensions.impl.BuildChooserSetting> <hudson.plugins.git.extensions.impl.BuildChooserSetting> <buildChooser class= "hudson.plugins.git.util.InverseBuildChooser" /> </hudson.plugins.git.extensions.impl.BuildChooserSetting> </extensions> </scm> Would this be considered a separate issue, or should this one be re-opened?

          Mark Waite added a comment -

          The change was intended to assure that multiple build chooser settings were evaluated in 2.4.4 the same as they were evaluated in 2.4.2 and prior. If 2.4.4 does not evaluate the same as 2.4.2, then I'll need to investigate further, since that means there was more than 1 change which damaged that behavior.

          Could you double check that the 2.4.4 behavior is inconsistent with the 2.4.2 behavior, and if it is, then reopen this bug for more investigation?

          Mark Waite added a comment - The change was intended to assure that multiple build chooser settings were evaluated in 2.4.4 the same as they were evaluated in 2.4.2 and prior. If 2.4.4 does not evaluate the same as 2.4.2, then I'll need to investigate further, since that means there was more than 1 change which damaged that behavior. Could you double check that the 2.4.4 behavior is inconsistent with the 2.4.2 behavior, and if it is, then reopen this bug for more investigation?

          Strange as it may be, it seems that 2.4.2, despite my prior experience, is consistent with 2.4.4, in that both of them only obey the first child node of the <extensions>.

          I guess at this point, I should open a new issue with that behavior, as the original problem of writing out a mangled XML was fixed.

          Zalan Meggyesi added a comment - Strange as it may be, it seems that 2.4.2, despite my prior experience, is consistent with 2.4.4, in that both of them only obey the first child node of the <extensions>. I guess at this point, I should open a new issue with that behavior, as the original problem of writing out a mangled XML was fixed.

          Mark Waite added a comment -

          That likely means I did some damage at some other point and inadvertently caused a loss of functionality.

          If you can isolate the version number where the behavior changed, that would help the investigation. I'd prefer that come in a separate bug report, since I think it is a different change than this change.

          Mark Waite added a comment - That likely means I did some damage at some other point and inadvertently caused a loss of functionality. If you can isolate the version number where the behavior changed, that would help the investigation. I'd prefer that come in a separate bug report, since I think it is a different change than this change.

            markewaite Mark Waite
            zmeggyesi Zalan Meggyesi
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: