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

Provided maven settings.xml in maven builder is lost

      I wanted to use the "Config File Provider plugin" to specify and reuse a maven settings.xml (Maven builder -> Settings file -> provided settings.xml). Everything seemed to work ok until i reopened the project's configuration page and stored the project: Now the specified settings.xml was lost! I made a copy of the project's config.xml before and compared it. The "settingsConfigId" element became empty, everytime i saved the project. It is only stored when i explicitly set the "provided settings" to use.

      This is very awkward, especially because the "Settings file" part is not seen right away when you open the project's configuration page.

          [JENKINS-15976] Provided maven settings.xml in maven builder is lost

          Markus Hoofe created issue -

          Since version 2.3 of the config-file-provider requires core 1.491 and the field "settingsConfigId" is deprecated and internally not used anymore. It only is read during startup to do the migration form the old to the new format.
          Instead of the old 'settingsConfigId' you should see a a new tag "settings" and/or "globalSettings" which will contain the same id as in the original one.
          The new tags will by stored in the config.xml when a the job gets saved the first time again (this is the same time when the old field gets removed from within the config.xml). If the job does not get resaved by a user, then the same information is used, but only in memory.
          So during startup a migration from the old format to the new format is done in memory and if a user opens the configuration screen of the job, then he sees the memory representation of the job and therefore the new config is visible for him. If he presses save, then the new model is saved and the old "settignsConfigId" is removed.

          From your description I'm not able to tell whether your configuration is broken or if you just don't like the location of the settings.xml configuration in the UI. Does your job still work or not?
          Did you reference a settings.xml provided by the config-file-provider plugin or did you define an explicit settings.xml in the old (removed) text field?

          Dominik Bartholdi added a comment - Since version 2.3 of the config-file-provider requires core 1.491 and the field "settingsConfigId" is deprecated and internally not used anymore. It only is read during startup to do the migration form the old to the new format. Instead of the old 'settingsConfigId' you should see a a new tag "settings" and/or "globalSettings" which will contain the same id as in the original one. The new tags will by stored in the config.xml when a the job gets saved the first time again (this is the same time when the old field gets removed from within the config.xml). If the job does not get resaved by a user, then the same information is used, but only in memory. So during startup a migration from the old format to the new format is done in memory and if a user opens the configuration screen of the job, then he sees the memory representation of the job and therefore the new config is visible for him. If he presses save, then the new model is saved and the old "settignsConfigId" is removed. From your description I'm not able to tell whether your configuration is broken or if you just don't like the location of the settings.xml configuration in the UI. Does your job still work or not? Did you reference a settings.xml provided by the config-file-provider plugin or did you define an explicit settings.xml in the old (removed) text field?

          Markus Hoofe added a comment -

          I forgot to mention that i am using the "freestyle" project's maven builder. Apart from that i am using a newly installed jenkins with the newest version (1.492). So all i did was:

          • Installing "Jenkins" (1.492)
          • Installing "Config File Provider Plugin" (2.3)
          • Creating a "Maven settings.xml" configuration ("MySettings")
          • Creating a new "Freestyle Software Project" ("Test")
          • Adding a "Invoke top-level Maven targets" build step
          • Clicking the "Advanced..." button to reveal more settings
          • Selecting "provided settings.xml" file in "Settings file"
          • Selecting the former created "MySettings" configuration in "Provided Settings"

          Running this job worked and i know the maven builder used the provided settings.xml, because it would not have worked otherwise (i added a server configuration for the deployment of artifacts). But as soon as i reopened the project configuration and clicked on "Save", the provided settings were lost! Thus the job failed due to the missing configuration AND i found out that any reference to the "MySettings" configuration was removed from "config.xml". The "settingsConfigId" element was still there, but it was empty!

          This is a snippet of config.xml when i created the job and everything was fine:

            <builders>
              <hudson.tasks.Maven>
                <targets>clean install</targets>
                <mavenName>maven-3.0.4</mavenName>
                <usePrivateRepository>false</usePrivateRepository>
                <settings class="org.jenkinsci.plugins.configfiles.maven.job.MvnSettingsProvider" plugin="config-file-provider@2.3">
                  <settingsConfigId>org.jenkinsci.plugins.configfiles.maven.MavenSettingsConfig1354471384133</settingsConfigId>
                </settings>
                <globalSettings class="jenkins.mvn.DefaultGlobalSettingsProvider"/>
              </hudson.tasks.Maven>
            </builders>
          

          And this happened AFTER i reopened it and saved it again (i did not change anything by the way, just clicked on "Save"):

            <builders>
              <hudson.tasks.Maven>
                <targets>clean install</targets>
                <mavenName>maven-3.0.4</mavenName>
                <usePrivateRepository>false</usePrivateRepository>
                <settings class="org.jenkinsci.plugins.configfiles.maven.job.MvnSettingsProvider" plugin="config-file-provider@2.3">
                  <settingsConfigId></settingsConfigId>
                </settings>
                <globalSettings class="jenkins.mvn.DefaultGlobalSettingsProvider"/>
              </hudson.tasks.Maven>
            </builders>
          

          I also created a "Maven 2/3 Project" - which i cannot use in my context by the way - and here the same settings were NOT lost after reopening and saving! So it might have something to do with the freestyle software project.

          I hope i cleared things up a bit and did not do something stupid, as i am new to jenkins. And thank you for fast response!

          Markus Hoofe added a comment - I forgot to mention that i am using the "freestyle" project's maven builder. Apart from that i am using a newly installed jenkins with the newest version (1.492). So all i did was: Installing "Jenkins" (1.492) Installing "Config File Provider Plugin" (2.3) Creating a "Maven settings.xml" configuration ("MySettings") Creating a new "Freestyle Software Project" ("Test") Adding a "Invoke top-level Maven targets" build step Clicking the "Advanced..." button to reveal more settings Selecting "provided settings.xml" file in "Settings file" Selecting the former created "MySettings" configuration in "Provided Settings" Running this job worked and i know the maven builder used the provided settings.xml, because it would not have worked otherwise (i added a server configuration for the deployment of artifacts). But as soon as i reopened the project configuration and clicked on "Save", the provided settings were lost! Thus the job failed due to the missing configuration AND i found out that any reference to the "MySettings" configuration was removed from "config.xml". The "settingsConfigId" element was still there, but it was empty! This is a snippet of config.xml when i created the job and everything was fine: <builders> <hudson.tasks.Maven> <targets>clean install</targets> <mavenName>maven-3.0.4</mavenName> <usePrivateRepository> false </usePrivateRepository> <settings class= "org.jenkinsci.plugins.configfiles.maven.job.MvnSettingsProvider" plugin= "config-file-provider@2.3" > <settingsConfigId>org.jenkinsci.plugins.configfiles.maven.MavenSettingsConfig1354471384133</settingsConfigId> </settings> <globalSettings class= "jenkins.mvn.DefaultGlobalSettingsProvider" /> </hudson.tasks.Maven> </builders> And this happened AFTER i reopened it and saved it again (i did not change anything by the way, just clicked on "Save"): <builders> <hudson.tasks.Maven> <targets>clean install</targets> <mavenName>maven-3.0.4</mavenName> <usePrivateRepository> false </usePrivateRepository> <settings class= "org.jenkinsci.plugins.configfiles.maven.job.MvnSettingsProvider" plugin= "config-file-provider@2.3" > <settingsConfigId></settingsConfigId> </settings> <globalSettings class= "jenkins.mvn.DefaultGlobalSettingsProvider" /> </hudson.tasks.Maven> </builders> I also created a "Maven 2/3 Project" - which i cannot use in my context by the way - and here the same settings were NOT lost after reopening and saving! So it might have something to do with the freestyle software project. I hope i cleared things up a bit and did not do something stupid, as i am new to jenkins. And thank you for fast response!

          ok, thanks - now I'm able to reproduce it.
          but I need to dig a bit deeper to solve this...

          Dominik Bartholdi added a comment - ok, thanks - now I'm able to reproduce it. but I need to dig a bit deeper to solve this...

          I've just confirmed with Stephen C. on IRC that this happens in the freestyle projects: the configuration setting cannot be set, it'll be lost like the original poster said.

          Would be great to see this fixed. While we can use the -s trick, having the setting there causes confusion.

          Miguel Almeida added a comment - I've just confirmed with Stephen C. on IRC that this happens in the freestyle projects: the configuration setting cannot be set, it'll be lost like the original poster said. Would be great to see this fixed. While we can use the -s trick, having the setting there causes confusion.

          Dominik Bartholdi added a comment - - edited

          It seems that a dropdown in a dropdown is an issue for an advanced section

          Dominik Bartholdi added a comment - - edited It seems that a dropdown in a dropdown is an issue for an advanced section

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/main/resources/org/jenkinsci/plugins/configfiles/maven/job/MvnGlobalSettingsProvider/config.jelly
          src/main/resources/org/jenkinsci/plugins/configfiles/maven/job/MvnSettingsProvider/config.jelly
          src/test/java/org/jenkinsci/plugins/configfiles/maven/job/MvnSettingsProviderTest.java
          http://jenkins-ci.org/commit/config-file-provider-plugin/40c66e9aeb51afd33999145437feb4c1c755bacb
          Log:
          [FIXED JENKINS-15976]

          "it" refers to the object that owns the page, such as FreeStyleProject.
          So a small object like SettingsProvider that contributes to those big
          guys should refer to itself as 'instance', not via 'it'.

          Also added a regression test case.

          Compare: https://github.com/jenkinsci/config-file-provider-plugin/compare/05f431815f32...40c66e9aeb51

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/resources/org/jenkinsci/plugins/configfiles/maven/job/MvnGlobalSettingsProvider/config.jelly src/main/resources/org/jenkinsci/plugins/configfiles/maven/job/MvnSettingsProvider/config.jelly src/test/java/org/jenkinsci/plugins/configfiles/maven/job/MvnSettingsProviderTest.java http://jenkins-ci.org/commit/config-file-provider-plugin/40c66e9aeb51afd33999145437feb4c1c755bacb Log: [FIXED JENKINS-15976] "it" refers to the object that owns the page, such as FreeStyleProject. So a small object like SettingsProvider that contributes to those big guys should refer to itself as 'instance', not via 'it'. Also added a regression test case. Compare: https://github.com/jenkinsci/config-file-provider-plugin/compare/05f431815f32...40c66e9aeb51
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Hello,
          sorry, I think I have to reopen this issue. It is still reproducible in Freestyle build jobs: Create such a job, add a Maven build step and set a settings.xml managed by "config file provider plugin".
          I debugged on this and identified the problem: After clicking "Save", the settings are de-serialized correclty on the server side, but are overwritten with presumably fallback-values right after that. The fallback values should be available through the constructor of the "Maven" class although. With my fix it works for me: https://github.com/jenkinsci/jenkins/pull/833

          Bastian Glöckle added a comment - Hello, sorry, I think I have to reopen this issue. It is still reproducible in Freestyle build jobs: Create such a job, add a Maven build step and set a settings.xml managed by "config file provider plugin". I debugged on this and identified the problem: After clicking "Save", the settings are de-serialized correclty on the server side, but are overwritten with presumably fallback-values right after that. The fallback values should be available through the constructor of the "Maven" class although. With my fix it works for me: https://github.com/jenkinsci/jenkins/pull/833
          Bastian Glöckle made changes -
          Resolution Original: Fixed [ 1 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

            domi Dominik Bartholdi
            mhoofe Markus Hoofe
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: