Publish Build Artefact (or Copy Files) appears to rewrite line endings on files it saves to "Visual Studio Team Services/TFS" from the original "LF" (unix) to "CRLF" (windows). For most of my stuff this wouldn't be a problem, except for the docker-entrypoint.sh shell scripts that get built into my linux images.
This manifests as none of my images working - giving errors about files not being found (the reality being that /bin/sh^M is never going to be found, but thats not what I wanted.
The only work around I can figure out is running dos2unix on all files that get copied into my images.
The Hosted agent is a Windows machine so it is not surprising that a copy would do that. What happens when you upload the same files from a Linux agent?
I've pointed it at a Hosted Linux preview and the line endings in the artefacts are now retained.
We run our builds using capabilities, since this build is essentially "convert git repo to artefact for release" it should be able to run anywhere the agent can. It's not really at all intuitive that we'll get different results dependant on host OS.
We are not losing or retaining. By default on Windows when Git clones and checks out code it replaces the line endings. So when we do a byte for byte copy it will get whatever is on disk.
I thought it could be a git issue so I added a .gitattributes file stating:
* text eol=lf
Which to my knowledge should ensure that all text files should have LF line endings. It did not appear to work though. Maybe I had the syntax wrong.
Either way I've switched the build queue for this project to a unix only one whilst I investigate. 馃憤
Same issue doesn't seem to be fixed / documented or with any workaround suggested in the official docs
what about this issue?, I have the same problem for Continuous Deployment in VM Scale Sets in my Azure portal.
Is this related to this? Or gives any helpful pointer?
https://developercommunity.visualstudio.com/content/problem/388664/azure-pipelines-get-sources-not-obeying-gitattribu.html
Read the last comment.
Most helpful comment
Same issue doesn't seem to be fixed / documented or with any workaround suggested in the official docs