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

Provided maven settings.xml in maven builder is lost

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            domi 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?

            Show
            domi 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?
            Hide
            mhoofe 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!

            Show
            mhoofe 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!
            Hide
            domi 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...

            Show
            domi 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...
            Hide
            wild_oscar 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.

            Show
            wild_oscar 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.
            Hide
            domi Dominik Bartholdi added a comment - - edited

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

            Show
            domi Dominik Bartholdi added a comment - - edited It seems that a dropdown in a dropdown is an issue for an advanced section
            Hide
            scm_issue_link 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

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

            Show
            bgloeckle 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
            Hide
            domi Dominik Bartholdi added a comment -

            hmm, strange - I'm not able to reproduce this.
            Which versions are you using?

            Show
            domi Dominik Bartholdi added a comment - hmm, strange - I'm not able to reproduce this. Which versions are you using?
            Hide
            bgloeckle Bastian Glöckle added a comment -

            I verified this again this morning. I used a fresh Jenkins 1.522 installation inside a Tomcat 7.0.41. There are two plugins installed into Jenkins: token-macro (1.7) and config-file-provider (2.5.1).
            Steps to reproduce:

            • Fresh installation
            • Go to configuration, add a "Maven settings.xml" in "Managed files"
            • Create a new Freestyle project
            • Add a "Execute Maven goals" build step
            • Click "Advanced"
            • Settings file: "provided settings.xml"
            • Choose the created settings.xml
            • Save
            • Re-open configuration of job and inspect the Advanced settings of the Maven build step -> "Settings file: Use default maven settings"
            Show
            bgloeckle Bastian Glöckle added a comment - I verified this again this morning. I used a fresh Jenkins 1.522 installation inside a Tomcat 7.0.41. There are two plugins installed into Jenkins: token-macro (1.7) and config-file-provider (2.5.1). Steps to reproduce: Fresh installation Go to configuration, add a "Maven settings.xml" in "Managed files" Create a new Freestyle project Add a "Execute Maven goals" build step Click "Advanced" Settings file: "provided settings.xml" Choose the created settings.xml Save Re-open configuration of job and inspect the Advanced settings of the Maven build step -> "Settings file: Use default maven settings"
            Hide
            mstein1 Markus Stein added a comment -

            Here's the same problem. I can reproduce it too, on Jenkins 1.522 with config-file-provider 2.5.1.
            Setting "provided global settings" then choose settings item.

            After save and open job again, it's lost.

            Show
            mstein1 Markus Stein added a comment - Here's the same problem. I can reproduce it too, on Jenkins 1.522 with config-file-provider 2.5.1. Setting "provided global settings" then choose settings item. After save and open job again, it's lost.
            Hide
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #2717
            [FIXES JENKINS-15976] After de-serializing changed job settings after "Save", the maven settings done by config-file-provider-plugin were overwritten blindly (presumably with fallback values). These fallback values should be set correctly in the constructor of the "Maven" class and do not need to be set explicitly after deserialization. (Revision 40f3b095aae871589b296e455dfad04f368c3dc3)
            [FIXED JENKINS-15976] update changelog (Revision 5a3d877164e37554fa93eb9c5f011b6001d23956)

            Result = SUCCESS
            bastian.gloeckle : 40f3b095aae871589b296e455dfad04f368c3dc3
            Files :

            • core/src/main/java/hudson/tasks/Maven.java

            imod : 5a3d877164e37554fa93eb9c5f011b6001d23956
            Files :

            • changelog.html
            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2717 [FIXES JENKINS-15976] After de-serializing changed job settings after "Save", the maven settings done by config-file-provider-plugin were overwritten blindly (presumably with fallback values). These fallback values should be set correctly in the constructor of the "Maven" class and do not need to be set explicitly after deserialization. (Revision 40f3b095aae871589b296e455dfad04f368c3dc3) [FIXED JENKINS-15976] update changelog (Revision 5a3d877164e37554fa93eb9c5f011b6001d23956) Result = SUCCESS bastian.gloeckle : 40f3b095aae871589b296e455dfad04f368c3dc3 Files : core/src/main/java/hudson/tasks/Maven.java imod : 5a3d877164e37554fa93eb9c5f011b6001d23956 Files : changelog.html
            Hide
            recampbell Ryan Campbell added a comment -

            40f3b095a claims to have fixed this issue, but was not automatically done for some reason.

            Show
            recampbell Ryan Campbell added a comment - 40f3b095a claims to have fixed this issue, but was not automatically done for some reason.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Glöckle Bastian
            Path:
            core/src/main/java/hudson/tasks/Maven.java
            http://jenkins-ci.org/commit/jenkins/40f3b095aae871589b296e455dfad04f368c3dc3
            Log:
            [FIXES JENKINS-15976] After de-serializing changed job settings after "Save", the maven settings done by config-file-provider-plugin were overwritten blindly (presumably with fallback values). These fallback values should be set correctly in the constructor of the "Maven" class and do not need to be set explicitly after deserialization.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Glöckle Bastian Path: core/src/main/java/hudson/tasks/Maven.java http://jenkins-ci.org/commit/jenkins/40f3b095aae871589b296e455dfad04f368c3dc3 Log: [FIXES JENKINS-15976] After de-serializing changed job settings after "Save", the maven settings done by config-file-provider-plugin were overwritten blindly (presumably with fallback values). These fallback values should be set correctly in the constructor of the "Maven" class and do not need to be set explicitly after deserialization.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: imod
            Path:
            core/src/main/java/hudson/tasks/Maven.java
            http://jenkins-ci.org/commit/jenkins/e034d632ec8ff6dfc80bb065f57fce9279547814
            Log:
            Merge branch 'JENKINS-15976' of https://github.com/bgloeckle/jenkins into bgloeckle-JENKINS-15976

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: imod Path: core/src/main/java/hudson/tasks/Maven.java http://jenkins-ci.org/commit/jenkins/e034d632ec8ff6dfc80bb065f57fce9279547814 Log: Merge branch ' JENKINS-15976 ' of https://github.com/bgloeckle/jenkins into bgloeckle- JENKINS-15976
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: imod
            Path:
            changelog.html
            http://jenkins-ci.org/commit/jenkins/5a3d877164e37554fa93eb9c5f011b6001d23956
            Log:
            [FIXED JENKINS-15976] update changelog

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: imod Path: changelog.html http://jenkins-ci.org/commit/jenkins/5a3d877164e37554fa93eb9c5f011b6001d23956 Log: [FIXED JENKINS-15976] update changelog
            Hide
            bgloeckle Bastian Glöckle added a comment -

            Sorry I've to reopen this again

            We're currently waiting for this change to be integrated into an official release.
            The changelog of 1.525 says that it was integrated, but when inspecting the git log, the commit was not integrated in the release: See the list of commits available on master but not on jenkins-1.525 tag: https://github.com/jenkinsci/jenkins/compare/jenkins-1.525...master (search for "JENKINS-15976"). Or you can have a look at the code of the Maven class that was built in the release: https://github.com/jenkinsci/jenkins/blob/jenkins-1.525/core/src/main/java/hudson/tasks/Maven.java (line 437f does not contain my changes).
            I think the changelog for 1.525 should be adjusted. I'd really love to see the changes appear in one of the next releases

            Show
            bgloeckle Bastian Glöckle added a comment - Sorry I've to reopen this again We're currently waiting for this change to be integrated into an official release. The changelog of 1.525 says that it was integrated, but when inspecting the git log, the commit was not integrated in the release: See the list of commits available on master but not on jenkins-1.525 tag: https://github.com/jenkinsci/jenkins/compare/jenkins-1.525...master (search for " JENKINS-15976 "). Or you can have a look at the code of the Maven class that was built in the release: https://github.com/jenkinsci/jenkins/blob/jenkins-1.525/core/src/main/java/hudson/tasks/Maven.java (line 437f does not contain my changes). I think the changelog for 1.525 should be adjusted. I'd really love to see the changes appear in one of the next releases
            Hide
            domi Dominik Bartholdi added a comment -

            some stuff got lost in the last RC, but the code is changed and will be in the next release

            changelog is sdjusted

            Show
            domi Dominik Bartholdi added a comment - some stuff got lost in the last RC, but the code is changed and will be in the next release changelog is sdjusted
            Hide
            bdellegrazie Brett Delle Grazie added a comment -

            Hi,
            I've added LTS as this bug effects current LTS 1.509.4
            Will the fix for this cleanly apply to current LTS? (1.509.4) or do we need to wait for LTS RC (1.532.1)?
            This particular issue is breaking several things in our setup.

            Show
            bdellegrazie Brett Delle Grazie added a comment - Hi, I've added LTS as this bug effects current LTS 1.509.4 Will the fix for this cleanly apply to current LTS? (1.509.4) or do we need to wait for LTS RC (1.532.1)? This particular issue is breaking several things in our setup.
            Hide
            domi Dominik Bartholdi added a comment -

            I don't think there is gonna be another 1.509.* release, so yes you'll have to wait for 1.532.1

            Show
            domi Dominik Bartholdi added a comment - I don't think there is gonna be another 1.509.* release, so yes you'll have to wait for 1.532.1

              People

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

                Dates

                Created:
                Updated:
                Resolved: