[JIRA] (JENKINS-49787) Jenkins.createProjectFromXml() formats xml differently than AbstractItem.save()

[aaandraaas@yahoo.com (JIRA)]

Petres Andras created an issue

Jenkins / JENKINS-49787 Jenkins.createProjectFromXml() formats xml differently than AbstractItem.save() Issue Type: Bug Assignee: Daniel Spilker Attachments: diff.png Components: core, job-dsl-plugin, jobconfighistory-plugin Created: 2018-02-28 07:36 Environment: Jenkins 2.106 job-dsl-plugin 1.68 jobConfigHistory plugin 2.18 Priority: Minor Reporter: Petres Andras 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? Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[o.v.nenashev@gmail.com (JIRA)]

Oleg Nenashev commented on JENKINS-49787

Re: Jenkins.createProjectFromXml() formats xml differently than AbstractItem.save() 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)

Add Comment

[mail@daniel-spilker.com (JIRA)]

Daniel Spilker updated an issue

Jenkins / JENKINS-49787

Jenkins.createProjectFromXml() formats xml differently than AbstractItem.save()

Change By: Daniel Spilker Component/s: job-dsl-plugin

Add Comment

[mail@daniel-spilker.com (JIRA)]

Daniel Spilker assigned an issue to Stefan Brausch

Jenkins / JENKINS-49787 Jenkins.createProjectFromXml() formats xml differently than AbstractItem.save()

Change By: Daniel Spilker Assignee: Daniel Spilker Stefan Brausch

Add Comment

[reto.hoehener@gmail.com (JIRA)]

Reto Hoehener commented on JENKINS-49787

Re: Jenkins.createProjectFromXml() formats xml differently than AbstractItem.save() 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.

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)