gl-vsts-tasks-file-patch
gl-vsts-tasks-file-patch copied to clipboard
Variable with backslash missing in output
I have variable $(CPath) with value C:\software I am trying to patch the following XML's LogFile node
<?xml version="1.0"?><Configuration>
<Runtime>
<LogFile>C:wnetRCdsfsd</LogFile>
</Configuration>
using Pach Content :
= /WnetConfiguration/Runtime/LogFile => "$(CPath)"
In the output XML, I am getting
<?xml version="1.0"?><Configuration>
<Runtime>
<LogFile>C:software</LogFile>
</Configuration>
As can be seen, output LogFile node is missing the backslash.
Hi @wahabshah and thank you for your report.
Could you upload us the debug logs of the task as mentionned here? It will help us to investigate where the problem happens :)
We'll try to fix your issue as soon as possible!
I'm away for a few days so I'll look into this later this week. However I think I know where this comes from. Variables are replace by vsts for early bound and by the task for late bound variable. In the both case this is just text replacement without any escaping and this must conflict with JSON escapement.
I think we should find a way to prevent vsts automatic evaluation of variables and then escape variables value before replacement.
A few unit tests around values and escaping and a fix are needed. As usual PR are welcome :)
Here is the log for the task with System.Debug set to true. It is failing as you can see on character next to the backslash
2016-08-22T19:52:58.5066223Z Set workingFolder to default: C:\agent-legacy\tasks\XmlPatch\1.1.1000
2016-08-22T19:52:59.1508799Z ##[debug]agent.workFolder=C:\agent-legacy\_work
2016-08-22T19:52:59.1518803Z ##[debug]loading inputs and endpoints
2016-08-22T19:52:59.1528807Z ##[debug]loading ENDPOINT_AUTH_PARAMETER_SYSTEMVSSCONNECTION_ACCESSTOKEN
2016-08-22T19:52:59.1538811Z ##[debug]loading ENDPOINT_AUTH_SCHEME_SYSTEMVSSCONNECTION
2016-08-22T19:52:59.1548815Z ##[debug]loading ENDPOINT_AUTH_SYSTEMVSSCONNECTION
2016-08-22T19:52:59.1548815Z ##[debug]loading INPUT_JSONPATCHCONTENT
2016-08-22T19:52:59.1548815Z ##[debug]loading INPUT_OUTPUTPATCHFILE
2016-08-22T19:52:59.1558819Z ##[debug]loading INPUT_SYNTAXTYPE
2016-08-22T19:52:59.1558819Z ##[debug]loading INPUT_XMLTARGETFILTERS
2016-08-22T19:52:59.1578827Z ##[debug]loading INPUT_XMLWORKINGDIR
2016-08-22T19:52:59.1578827Z ##[debug]loaded 8
2016-08-22T19:52:59.4299915Z ##[debug]XmlWorkingDir=C:\agent-legacy\_work\3da06a071\WnetPacket\deploy\WnetInstallation\Common
2016-08-22T19:52:59.4299915Z ##[debug]JsonPatchContent== /WnetConfiguration/Runtime/LogFile => "C:\wnetRC"
2016-08-22T19:52:59.4299915Z ##[debug]OutputPatchFile=true
2016-08-22T19:52:59.4309919Z ##[debug]SyntaxType=slick
2016-08-22T19:52:59.4309919Z ##[debug]XmlTargetFilters=Common_EF.config
2016-08-22T19:52:59.4309919Z ##[debug]Namespaces=null
2016-08-22T19:52:59.4339931Z = /WnetConfiguration/Runtime/LogFile => "C:\wnetRC"
2016-08-22T19:52:59.4339931Z = /WnetConfiguration/Runtime/LogFile => "C:\wnetRC"
2016-08-22T19:52:59.4349935Z SyntaxError: Unexpected token w
2016-08-22T19:52:59.4349935Z ##[debug]task result: Failed
2016-08-22T19:52:59.4399955Z ##[error]SyntaxError: Unexpected token w
Hi @wahabshah, this is exactly the issue I diagnosed. The bad news is that in this case variable replacement is done by vsts itself and they do not provide a way to retrieve unexpanded input.
So basically we can't know where a variable was located in the string and might need JSON escaping.
The easiest way to fix this would be for you to escape your variable yourself i.e. $(CPath)
should be set to C:\\wnetRC
We might consider adding a custom syntax like #(VariableName)
which would perform the escaping in the future
Thanks @sandorfr I am using your advice of using double slash in the variable to escape it for the time being. Just checked it and it is working as expected.
@wahabshah Considering there won't be any way to do this using native vsts variable suppport, I'll will implement the custom syntax soon. I'll keep you posted when this will be available.
Trying to figure out the priority of this one as I really feel uncomfortable introducing a custom expand syntax.
If someone is interested in this feature please leave a comment.