Description of problem: I have deployed the GA 3.2 appliance and the behavior is the same. == Steps to Reproduce == 1. Create a new Automate Domain CASE_01456361 2. Create a LineEndings namespace 3. Create a LineEndings class 4. Create a method hello_world. 5. Add some logging lines to hello_word 6. Save/Add the method 7. Export the domains 8. Unzip the export file 9. Examine the file vi -b CASE_01456361/LineEndings/LineEndings.class/__methods__/hello_world.rb Note that a 3.1 export uses Unix line endings and a 3.2 export uses Windows line endings. A diff will show that every line has changed. This causes complications when managing the code via source control and working on both 3.1 and 3.2 environments. 1,5c1,5 < # < # Description: <Method description here> < # < $evm.log(:info, "Hello World") < $evm.log(:info, "Checking the line endings.") --- > # > # Description: <Method description here> > # > $evm.log(:info, "Hello World") > $evm.log(:info, "Checking the line endings.") Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Josh - I think these line endings are being added when the UI passes the method text to be saved in the database. Do you have any older methods in the export, maybe something in the ManageIQ domain, you can verify does not have the Windows line endings. For example I looked at "ManageIQ/System/Request.class/__methods__/inspectme.rb" which did not show this issue. Also using a tool like DbVisualizer I am able to see the miq_ae_methods text for the data column in hex and there I see the Windows line ending characters (0x0D 0x0A) on newer methods.
Asked the customer the following question, Do you see the same behavior when exporting older methods that would reside in the ManageIQ domain or anything custom that has been migrated over? Their response was, This appears to change when the editor interface is used on the methods. Files that are imported, but not edited still export as Unix line endings.
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/49a60cd709553f88929b27669e5e96ebde4c4cd1 commit 49a60cd709553f88929b27669e5e96ebde4c4cd1 Author: Harpreet Kataria <hkataria> AuthorDate: Thu Sep 3 10:43:54 2015 -0400 Commit: Harpreet Kataria <hkataria> CommitDate: Thu Sep 3 10:44:18 2015 -0400 Fixed issue where textarea adds \r\n for newline characters. - Changed 'miqSerializeForm' JS method to replace '%0D%0A' with '%0A' in the serialized form data, this is caused because 'textarea' form element adds \r\n characters in the data for the newline characters. - Added Jasmine spec test to verify the fix https://bugzilla.redhat.com/show_bug.cgi?id=1234465 app/assets/javascripts/miq_application.js | 2 +- spec/javascripts/miq_application_spec.js | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) create mode 100644 spec/javascripts/miq_application_spec.js
https://github.com/ManageIQ/manageiq/pull/4128
Detected commit referencing this ticket while ticket status is POST.
https://github.com/ManageIQ/manageiq/pull/3978
https://github.com/ManageIQ/manageiq/pull/4262
Checked in 5.5.0.1-alpha1. I created a custom method, did an export and then examined contents of the method's .rb file from the exported archive. The CR character (0D) is not present. According to the textarea specification, the newline is CRLF, so the filtering from the PR is working.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2551