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

Git plugin writing out incorrect settings

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            Fixed in git plugin 2.4.4, released 24 Mar 2016

            Show
            markewaite Mark Waite added a comment - Fixed in git plugin 2.4.4, released 24 Mar 2016
            Hide
            zmeggyesi 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?

            Show
            zmeggyesi 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?
            Hide
            markewaite 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?

            Show
            markewaite 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?
            Hide
            zmeggyesi 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.

            Show
            zmeggyesi 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.
            Hide
            markewaite 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.

            Show
            markewaite 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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: