[JENKINS-33695] Git plugin writing out incorrect settings

Type: Bug
Resolution: Fixed
Priority: Major
Component/s: git-client-plugin, git-plugin
Labels:
None
Environment:
Jenkins: 1.653
git-client: 1.19.6
git: 2.4.3

Similar Issues:
Powered by SuggestiMate

Show

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.

is related to

JENKINS-33811 git plugin or jenkins remove my "check to a subdirectory" field

Closed

JENKINS-35248 Additional Behaviours not saved when Jenkins updated

Closed

JENKINS-33564 Sections of "Git" SCM configuration can be X'd out but not restored

Closed

Zalan Meggyesi created issue - 2016-03-21 15:40

Zalan Meggyesi made changes - 2016-03-21 20:22

Description

Original: 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.

New: 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.

Zalan Meggyesi made changes - 2016-03-21 20:23

Description

Original: 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.

New: 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.

Mark Waite made changes - 2016-03-22 00:23

Assignee

Original: Mark Waite [ markewaite ]

Zalan Meggyesi added a comment - 2016-03-22 05:20

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)?

Zalan Meggyesi added a comment - 2016-03-22 05:20 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)?

Thomas Spencer added a comment - 2016-03-22 09:18

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.

Thomas Spencer added a comment - 2016-03-22 09:18 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.

Mark Waite added a comment - 2016-03-22 11:58 - edited

tspencer and zmeggyesi 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.

Mark Waite added a comment - 2016-03-22 11:58 - edited tspencer and zmeggyesi 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.

Mark Waite made changes - 2016-03-22 11:59

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. ]

Zalan Meggyesi added a comment - 2016-03-22 12:03

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 - 2016-03-22 12:03 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 - 2016-03-22 13:02

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 - 2016-03-22 13:02 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.

Assignee:: Mark Waite

Reporter:: Zalan Meggyesi

Votes:: 4 Vote for this issue

Watchers:: 8 Start watching this issue

Created:: 2016-03-21 15:40

Updated:: 2019-10-23 01:28

Resolved:: 2016-03-25 04:45

Jenkins

Details

Description

Attachments

Issue Links

Activity

Collapse comment: Zalan Meggyesi added a comment - 2016-03-22 05:20

Expand comment: Zalan Meggyesi added a comment - 2016-03-22 05:20

Collapse comment: Thomas Spencer added a comment - 2016-03-22 09:18

Expand comment: Thomas Spencer added a comment - 2016-03-22 09:18

Collapse comment: Mark Waite added a comment - 2016-03-22 11:58, Edited by Mark Waite - 2016-03-22 12:00

Expand comment: Mark Waite added a comment - 2016-03-22 11:58, Edited by Mark Waite - 2016-03-22 12:00

Collapse comment: Zalan Meggyesi added a comment - 2016-03-22 12:03

Expand comment: Zalan Meggyesi added a comment - 2016-03-22 12:03

Collapse comment: Mark Waite added a comment - 2016-03-22 13:02

Expand comment: Mark Waite added a comment - 2016-03-22 13:02

People

Dates