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

config.xml files do not end in newline

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
    • Similar Issues:

      Description

      config.xml files for global config and for job config are not well-formed text files; the last line does not end in a linebreak

      {causing UNIX tools that rely on well-formed text files to break}

      this is nightmarish when editing the files manually and using git to track changes to them, a pattern which is otherwise very successful. editors like vim save only well-formed text files, which are then malformed by jenkins when it touches them.

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          As you consider this to be a bug, please specify a reference that mandates well-formed XML files need to end with a line break.

          Show
          danielbeck Daniel Beck added a comment - As you consider this to be a bug, please specify a reference that mandates well-formed XML files need to end with a line break.
          Hide
          teleshoes Elliot Wolk added a comment -

          i didnt say they werent well-formed XML files. i said that they are not well-formed text files.

          POSIX is a widely-accepted standard. here are the relevant POSIX definitions:

          3.397 Text File
          A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed

          {LINE_MAX}

          bytes in length, including the <newline> character.

          3.206 Line
          A sequence of zero or more non-<newline> characters plus a terminating <newline> character.

          http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html

          {the config.xml files do not meet this definition. they are <file>s containing a sequence of zero or more <line>s followed by one or more non-<newline> characters.}

          however, it is much more practically important to note that many standard, popular, extremely widely-deployed tools rely on this definition

          {vim, cat, and read being just a few examples}

          . there are no tools that i ever heard of that require special lines NOT to end in the newline character.

          Show
          teleshoes Elliot Wolk added a comment - i didnt say they werent well-formed XML files. i said that they are not well-formed text files. POSIX is a widely-accepted standard. here are the relevant POSIX definitions: 3.397 Text File A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character. 3.206 Line A sequence of zero or more non-<newline> characters plus a terminating <newline> character. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html {the config.xml files do not meet this definition. they are <file>s containing a sequence of zero or more <line>s followed by one or more non-<newline> characters.} however, it is much more practically important to note that many standard, popular, extremely widely-deployed tools rely on this definition {vim, cat, and read being just a few examples} . there are no tools that i ever heard of that require special lines NOT to end in the newline character.
          Hide
          pauloricardomg Paulo Motta added a comment -

          I'm also having the same issue.

          I use chef to manage my jenkins config files (jobs, plugins, etc), so whenever one of these files is edited by Unix tools such as VI, a newline is appended to the end of file, causing the file to be reloaded everytime chef is applied (since it's different from the jenkins parsed file, without newline).

          I don't remember having this problem with verison 1.563, but now that upgraded to 1.590 started happening, so probably it was introduced recently.

          Show
          pauloricardomg Paulo Motta added a comment - I'm also having the same issue. I use chef to manage my jenkins config files (jobs, plugins, etc), so whenever one of these files is edited by Unix tools such as VI, a newline is appended to the end of file, causing the file to be reloaded everytime chef is applied (since it's different from the jenkins parsed file, without newline). I don't remember having this problem with verison 1.563, but now that upgraded to 1.590 started happening, so probably it was introduced recently.
          Hide
          pauloricardomg Paulo Motta added a comment -

          I was wrong. The problem also happens in 1.563.

          Show
          pauloricardomg Paulo Motta added a comment - I was wrong. The problem also happens in 1.563.
          Hide
          danielbeck Daniel Beck added a comment -

          Calling this one an improvement makes more sense IMO. Jenkins, a Java application, runs on Windows as well, and text editors there don't add trailing newlines, so the applicability of POSIX on Jenkins isn't a given.

          While it should be straightforward to just add a newline to the end of every XmlFile, the problem is how to introduce this. Otherwise all users will see changes to files for no real reason when they didn't modify XML configuration using a Unix tool.

          "Only append if the previous file ended in a new line" maybe? That would be weird (why do some files end in newlines while others don't?), and you still get a change recorded whenever you edit a job's file for the first time.

          Show
          danielbeck Daniel Beck added a comment - Calling this one an improvement makes more sense IMO. Jenkins, a Java application, runs on Windows as well, and text editors there don't add trailing newlines, so the applicability of POSIX on Jenkins isn't a given. While it should be straightforward to just add a newline to the end of every XmlFile, the problem is how to introduce this. Otherwise all users will see changes to files for no real reason when they didn't modify XML configuration using a Unix tool. "Only append if the previous file ended in a new line" maybe? That would be weird (why do some files end in newlines while others don't?), and you still get a change recorded whenever you edit a job's file for the first time.
          Hide
          teleshoes Elliot Wolk added a comment -

          perhaps a less weird way to describe your proposal would be to format all lines the same by default, except when the only difference is that the last line in the old file did not end in newline. this would make it so that you dont get a change recorded when you edit a jobs file for the first time, and it would still be stable and backwards-compatible.

          Show
          teleshoes Elliot Wolk added a comment - perhaps a less weird way to describe your proposal would be to format all lines the same by default, except when the only difference is that the last line in the old file did not end in newline. this would make it so that you dont get a change recorded when you edit a jobs file for the first time, and it would still be stable and backwards-compatible.
          Hide
          teleshoes Elliot Wolk added a comment -

          i would like to point out, also, that editing config files without making changes is ALREADY allowed to produce a file with a difference checksum. it happens all the time, if you upgrade jenkins or any plugins. it would be unlikely for this to be the only change anyway.

          Show
          teleshoes Elliot Wolk added a comment - i would like to point out, also, that editing config files without making changes is ALREADY allowed to produce a file with a difference checksum. it happens all the time, if you upgrade jenkins or any plugins. it would be unlikely for this to be the only change anyway.

            People

            • Assignee:
              Unassigned
              Reporter:
              teleshoes Elliot Wolk
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: