Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Component/s: core, jobconfighistory-plugin
-
Labels:None
-
Environment:Jenkins 2.106
job-dsl-plugin 1.68
jobConfigHistory plugin 2.18
-
Similar Issues:
Description
Hello,
We generate our jobs using job-dsl plugin and we want to track custom changes to jobs using job-config-history plugin which compares job xml. Note that job-dsl-plugin relies on Jenkins.createProjectFromXml() to generate job xml. We noticed that after a generated job is saved (via the web UI) or a build is started, the job xml is rewritten via AbstractItem.save() adding a change to job config history. The differences are (see image attached):
- XML version 1.1 in file generated by save versus version 1.0 (introduced in Jenkins 2.105)
- different indentation
- different order of tags
Is there a way to assure that job xml formatting is independent of the way of creation?
Attachments
Activity
IIUC it is not and XML 1.1 regression. Even before that Jenkins used to override config.xml when resaving the object on its own. Jenkins does not store information about the original formatting in its data model and does not retain it when saving. So any JobDSL-generated config may have changed anyway.
Using plain diffs for such purpose in Jib Config History is questionable. XMLDiff would be preferable though it requires more computations.
One of the way to prevent the diff in this case would be to make Jenkins to deserialize object and save it instead of putting the original XML and then loading from it (code is here: https://github.com/jenkinsci/jenkins/blob/a79fdaa4b34b8f7fddb39bed3eabf4763940d11b/core/src/main/java/hudson/model/ItemGroupMixIn.java#L260-L309)
Would be nice if at least the empty element strategy could be consistent within the file: Either expand or collapse all empty tags.
We also backup (and version) our hundreds of job confix.xml files, and sometimes modify them programmatically. Currently it is impossible to modify just a single element with an XML processing library like JDOM, without getting a ton of changes because of the inconsistent empty tags.
The whitespace differences are not a problem, as for example the eclipse diff editor can be configured to ignore those.