-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins 2.190.2 (docker)
config-file-provider-plugin 3.6.2
configuration-as-code-plugin 1.34
-
-
config-file-provider 3.9.0
In our organization, we configure our jenkins instances using configuration-as-code for initial provisioning, but allow changes to the configuration over time.
When providing a set of config files like that and modifying a configuration like maven settings, the edited object does not get modified, instead a new config file object with the same id is created when saving:
grep -B 1 "<id>" org.jenkinsci.plugins.configfiles.GlobalConfigFiles.xml
<org.jenkinsci.plugins.configfiles.maven.GlobalMavenSettingsConfig>
<id>GlobalSettingsNexus</id>
--
<org.jenkinsci.plugins.configfiles.maven.GlobalMavenSettingsConfig>
<id>GlobalSettingsNexus</id>
--
<org.jenkinsci.plugins.configfiles.maven.GlobalMavenSettingsConfig>
<id>GlobalSettingsNexus</id>
When jobs request a config file by id, which instance they get is undefined.After some investigation, the collection of ConfigFile objects gets saved as a standard java.util.set instead of the TreeSet defined by the class.:
head -4 org.jenkinsci.plugins.configfiles.GlobalConfigFiles.xml <?xml version='1.1' encoding='UTF-8'?> <org.jenkinsci.plugins.configfiles.GlobalConfigFiles plugin="config-file-provider@3.6.2"> <configs class="set"> <org.jenkinsci.plugins.configfiles.maven.GlobalMavenSettingsConfig>
which should be (this is from a jenkins configured using the UI):
head -4 ../jenkins-2.176.2/org.jenkinsci.plugins.configfiles.GlobalConfigFiles.xml <?xml version='1.1' encoding='UTF-8'?> <org.jenkinsci.plugins.configfiles.GlobalConfigFiles plugin="config-file-provider@3.5"> <configs class="sorted-set"> <comparator class="org.jenkinsci.plugins.configfiles.GlobalConfigFiles$1"/>
We have a YAML file with our maven and node settings which looks like this:
unclassified: globalConfigFiles: configs: - globalMavenSettings: comment: "global settings" content: |- <?xml version="1.0" encoding="UTF-8" standalone="no"?> ...
The CasC configurator calls GlobalConfigFiles.setConfigs() with a normal java.util.Set, overrding the internal treeset and leading to the behavior described above.
A setter should not change the datastructure if you rely on the sorting behavior
To fix: The setter should internally convert its Collection parameter to a TreeSet with the correct Comparator
