When using the CLI or Rest API, Jenkins is saving the config.xml a different xml than I am providing. Specifically it is removing the first EOL, adding carriage returns, and replacing empty xml tags with self closing ones.

I manage Jenkins instances for my organization. Each has a "test" instance that is a mirror of the prod one. Developers can experiment with things like changes to jobs and interactions with new plugins on the test version and we can port them to the prod one where configure permissions are disabled. For a first time copy the Job Import Plugin works but for edits to existing ones I have to either manually duplicate the changes or script something.

I have tried this with both the CLI jar and groovy rest client. I get the config.xml from the test and prod servers. I perform a diff which lets me quickly see what the changes are and if approved will update the prod instance (job-update for CLI, POST for rest).

If a job is edited in the Jenkins UI the config.xml is saved with newlines. When updated through one of the remote tools it is saved with carriage returns and newlines. So, if I get the xml I just updated and diff it to the one I just sent they will register as completely different.

The config xmls retrieved will have carriage returns if the last modification was was from a remote update or just newlines if the last edit was in the UI.

I have looked at the requests I am sending and they do not have carriage returns. I looked at the code for CLI saves and it is creating a file from the parsed xml model rather than the supplied xml string. It removes a line break between the xml preamble and root <project> tag, saves each line with a carriage return and writes out self-closing tags. [edit: last sentence is describing observed behaviour not something seen in the code]

This messes up the Job Configuration History plugin as a one line change displays as if every line is changed. This also interferes with my local diff before sending the update.

The two images attached (missing-eol and exact-same-config) are from back to back runs of the update script, meaning the configurations are exactly the same. The config history plugin thinks the entire file has been changed. Even with a manual correction for the carriage returns, my local diff shows differences because of the tag differences.

The third (ui-save-no-change) is from a manual save in the UI (click "configure", click "save" with no changes). With no content change, we see that the <project> tag is again on its own line and

If I'm not mistaken about the cause, is it feasible to have Jenkins save the configuration consistently regardless of how the configuration has changed?