Gitlab WebUI creates invalid symbols for newlines, breaks behavior
Summary
When creating a git tag via the web interface containing newlines (\n) only carriage returns are inserted (\r) which breaks git/unix tools and expected behavior.
Steps to reproduce
Create tags online in the editor, pull them locally, view them and see that the newlines are gone.
Example Project
https://gitlab.com/olliver/sandbox/bugs/git-tags-breakage
Here tags v2.3 and v2.4 can be seen. Breakage behavior (which in this case also breaks the pipeline, as that is good as it was what I was after) are here:
Where 'breakage' means, the content is not properly stored in the variable/file. Only the last line remains.
Also it appears that the pipeline render er omits duplicate newlines, but I guess 'that's ok'
The tag renderer in the WebUI does interpret the \r as newlines and does show it appropriately.
What is the current bug behavior?
Newlines get replaced (or newlines are never entered, but only carriage returns are
What is the expected correct behavior?
As git, and git tags are unix tools (git on windows runs on a linux sort of shell), newlines should be used to not break tools everywhere.
Relevant logs and/or screenshots
[oliver@3of9:~/src/sandbox/bugs/git-tags-breakage]% git tag \
--format="%(contents:subject)%0a%0a%(contents:body)" \
--list v2.3
Release branch for v2.3^M ^M with newlines^M ^M and^M ^M so^M ^M much more!
[oliver@3of9:~/sandbox/bugs/git-tags-breakage]% git tag \
--format="%(contents:subject)%0a%0a%(contents:body)" \
--list v2.4
These are multiple lines
but without
any modifications!
whopp
and in hex ...
00000000 52 65 6c 65 61 73 65 20 62 72 61 6e 63 68 20 66 |Release branch f|
00000010 6f 72 20 76 32 2e 33 0d 20 0d 20 77 69 74 68 20 |or v2.3. . with |
00000020 6e 65 77 6c 69 6e 65 73 0d 20 0d 20 61 6e 64 0d |newlines. . and.|
00000030 20 0d 20 73 6f 0d 20 0d 20 6d 75 63 68 20 6d 6f | . so. . much mo|
00000040 72 65 21 0a 0a 0a |re!...|
And looking closer, we can actually see two things, for one, that instead of the newline entered into the text field of the webui, they get saved as '0d 20' and because of this, we see that the entire git tag message, is ONLY the subject. We can prove this removing the double newlines from the subject/content separator:
[oliver@3of9:~/src/sandbox/bugs/gitlab-newline-breakage]% git tag \
--format="%(contents:subject)(contents:body)" \
--list v2.3 | hexdump -C
00000000 52 65 6c 65 61 73 65 20 62 72 61 6e 63 68 20 66 |Release branch f|
00000010 6f 72 20 76 32 2e 33 0d 20 0d 20 77 69 74 68 20 |or v2.3. . with |
00000020 6e 65 77 6c 69 6e 65 73 0d 20 0d 20 61 6e 64 0d |newlines. . and.|
00000030 20 0d 20 73 6f 0d 20 0d 20 6d 75 63 68 20 6d 6f | . so. . much mo|
00000040 72 65 21 28 63 6f 6e 74 65 6e 74 73 3a 62 6f 64 |re!(contents:bod|
00000050 79 29 0a |y).|
This also means GitLab not only breaks git tagging, but also doesn't follow 'best practices' and treats tags as 'one line subject items only. This may also be the reason that CI_COMMIT_TAG_MESSAGE is not yet exposed as an oversight (See #27615). And possibly aslo why releases have the 'release description' as its own database entry, rather then firstly using the tag message, and only if it needs to be modified add additional release information (new issue? :-p)
Output of checks
This bug happens on GitLab.com
Possible fixes
Do not use \r, but the traditional \n when user enters data. I understand a lot of webdevelopers nowadays use Mac's, and the battle beteen CRLF CR and LF, but isn't CR only something from 'ancient mac days'?. In this case, we are seeing things break even on gitlab.com (well the pipeline steps) and since (most) pipelines tend to run on a linux based docker, that should be the primary supported character.
Possibly related to #28988
P.S. to work around it, sed can be used to work around it ...
[oliver@3of9:~/src/sdandbox/git-tag-breakage]% git tag \
--format="%(contents:subject)%0a%0a%(contents:body)" \
--list v2.3 | sed 's|\r |\n|g' | hexdump -C
00000000 52 65 6c 65 61 73 65 20 62 72 61 6e 63 68 20 66 |Release branch f|
00000010 6f 72 20 76 32 2e 33 0a 0a 77 69 74 68 20 6e 65 |or v2.3..with ne|
00000020 77 6c 69 6e 65 73 0a 0a 61 6e 64 0a 0a 73 6f 0a |wlines..and..so.|
00000030 0a 6d 75 63 68 20 6d 6f 72 65 21 0a 0a 0a |.much more!...|