-
Bug
-
Resolution: Fixed
-
Major
-
Powered by SuggestiMate
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.
- is related to
-
JENKINS-20431 Can't select "Settings file" for maven build step in free-style project
-
- Closed
-
[JENKINS-15976] Provided maven settings.xml in maven builder is lost
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...
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.
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
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
hmm, strange - I'm not able to reproduce this.
Which versions are you using?
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"
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.
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
40f3b095a claims to have fixed this issue, but was not automatically done for some reason.
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.
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
Code changed in jenkins
User: imod
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/5a3d877164e37554fa93eb9c5f011b6001d23956
Log:
[FIXED JENKINS-15976] update changelog
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
some stuff got lost in the last RC, but the code is changed and will be in the next release
changelog is sdjusted
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.
I don't think there is gonna be another 1.509.* release, so yes you'll have to wait for 1.532.1
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?