Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-49787

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • 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

          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          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)

          Show
          oleg_nenashev Oleg Nenashev added a comment - 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 )
          Hide
          rho Reto Hoehener added a comment -

          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.

           

          Show
          rho Reto Hoehener added a comment - 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.  

            People

            Assignee:
            stefanbrausch Stefan Brausch
            Reporter:
            apetres Petres Andras
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: