domi commented on Bug JENKINS-15976

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?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to