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

Git plugin writing out incorrect settings

    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

            zmeggyesi Zalan Meggyesi created issue -
            zmeggyesi Zalan Meggyesi made changes -
            Field Original Value New Value
            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.
            Consider the following excerpt from a job's config.xml:

            {quote}<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>{quote}

            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.
            zmeggyesi Zalan Meggyesi made changes -
            Description Consider the following excerpt from a job's config.xml:

            {quote}<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>{quote}

            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.
            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.
            markewaite Mark Waite made changes -
            Assignee Mark Waite [ markewaite ]
            Hide
            zmeggyesi Zalan Meggyesi added a comment -

            That's interesting, for a year and a half (at least) I've used this job configuration by having both options enabled.

            If you now set up the frontend to allow only one, is there any way I'll be able to retain the previous operation (obeying both the inverse and the ancestry strategy)?

            Show
            zmeggyesi Zalan Meggyesi added a comment - That's interesting, for a year and a half (at least) I've used this job configuration by having both options enabled. If you now set up the frontend to allow only one, is there any way I'll be able to retain the previous operation (obeying both the inverse and the ancestry strategy)?
            Hide
            tspencer Thomas Spencer added a comment -

            I had to sign up for an account just so I could comment on this.

            This is an issue caused by the latest 2.4.3 version of the plugin. I spent several hours figuring out why my configs were getting changed and things I set were getting removed. After I reverted to the 2.4.2 version the configs kept all the settings like I expected.

            The tricky thing about this is that if you load the config page for the job it looks like everything is set properly. But if you bounce the server (really reloading the configs from scratch) then it becomes apparent that the configs are messed up.

            There were a lot of changes in the code in this release. Anytime I see transient being added and low level access to the Jenkins api's I get suspicious. Something in all those changes caused this issue and it is a major problem.

            Show
            tspencer Thomas Spencer added a comment - I had to sign up for an account just so I could comment on this. This is an issue caused by the latest 2.4.3 version of the plugin. I spent several hours figuring out why my configs were getting changed and things I set were getting removed. After I reverted to the 2.4.2 version the configs kept all the settings like I expected. The tricky thing about this is that if you load the config page for the job it looks like everything is set properly. But if you bounce the server (really reloading the configs from scratch) then it becomes apparent that the configs are messed up. There were a lot of changes in the code in this release. Anytime I see transient being added and low level access to the Jenkins api's I get suspicious. Something in all those changes caused this issue and it is a major problem.
            Hide
            markewaite Mark Waite added a comment - - edited

            Thomas Spencer and Zalan Meggyesi thanks very much for detecting the problem, and for isolating it to the changes made between 2.4.2 and 2.4.3. Please switch your installation back to 2.4.2 so you're not affected by this bug that I introduced in 2.4.3.

            I'll bisect the changes between 2.4.2 and 2.4.3 to identify the change caused the failure. Once that's been isolated, I'll add an automated test to check that the bug does not reappear in a future release and deliver a release of the plugin to fix this bug.

            My apologies that I didn't detect that multiple build chooser settings was an allowed and expected condition.

            Show
            markewaite Mark Waite added a comment - - edited Thomas Spencer and Zalan Meggyesi thanks very much for detecting the problem, and for isolating it to the changes made between 2.4.2 and 2.4.3. Please switch your installation back to 2.4.2 so you're not affected by this bug that I introduced in 2.4.3. I'll bisect the changes between 2.4.2 and 2.4.3 to identify the change caused the failure. Once that's been isolated, I'll add an automated test to check that the bug does not reappear in a future release and deliver a release of the plugin to fix this bug. My apologies that I didn't detect that multiple build chooser settings was an allowed and expected condition.
            markewaite Mark Waite made changes -
            Comment [ That's an interesting condition. As far as I understand the build chooser implementation, the implementation expects that you will choose one of them. As far as I can tell, you're correct that it is a bug that the plugin allows the user to write more than 1 build chooser setting to a job definition.

            I don't know what it would mean to have multiple build choosers selected.

            In my collection of 2100+ verification jobs, the 30 which include a BuildChooserSetting all have exactly 1 setting.

            I believe it is intentional that only one of the build chooser setting values is used. ]
            Hide
            zmeggyesi 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)?

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

            Show
            markewaite 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.
            markewaite Mark Waite made changes -
            Assignee Mark Waite [ markewaite ]
            markewaite Mark Waite made changes -
            Link This issue is related to JENKINS-33564 [ JENKINS-33564 ]
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            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
            markewaite Mark Waite made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Link This issue is related to JENKINS-33811 [ JENKINS-33811 ]
            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.
            markewaite Mark Waite made changes -
            Link This issue is related to JENKINS-35248 [ JENKINS-35248 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 169659 ] JNJira + In-Review [ 198656 ]
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

              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: