Job log completely strips CRCRLF lines

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

Lines ending with \r\r\n are missing from the job logs, although they are visible in the raw output.

Steps to reproduce

Either:

• In a job on a non-windows runner, write something\r\r\n to stdout -- this is probably not very likely to happen.
• In a job on a Windows runner, write something\r\n to stdout -- this happens all the time, e.g. when outputting contents of files with Windows line endings (\r\n instead of \n). I can provide more real-life examples if necessary.

Example Project

https://gitlab.com/selimb/missing-lines/-/jobs/564023225

I wasn't sure how to get a Windows runner with the public/free CI, but the company I work for uses Windows runners -- those repos are self-hosted and internal.

What is the current bug behavior?

The line line CRCRLF is missing from the "interactive" job output window, but is visible in the raw output.

What is the expected correct behavior?

The "interactive" job output window should show either (with line numbers):

Option 1

23 line CRCRLF
24
25 line CRLF
26 line LF

Option 2

23 line CRCRLF
24 line CRLF
25 line LF

All text editors/viewers that I know of (tried notepad++, vscode, chrome, firefox) will render \r\r\n as in option 1, although I believe most terminals will render it as in option 2.

While Option 1 will more closely match the raw output, Option 2 will more likely match the output of rerunning the command in a terminal. To be honest, I don't really have a preference.

Relevant logs and/or screenshots

raw:

[0;m[32;1m$ python -c "import sys; sys.stdout.write('line CRCRLF\r\r\nline CRLF\r\nline LF\n')"[0;m
line CRCRLF

line CRLF
line LF

and running that on https://www.python.org/shell/:

>>> import sys; sys.stdout.write('line CRCRLF\r\r\nline CRLF\r\nline LF\n')
line CRCRLF
line CRLF
line LF
33

Output of checks

This bug happens on GitLab.com

Possible fixes

I suspect the bug is in the backend, because the CRCRLF line is also missing in the response from the trace.json response: