在我的vNext-build-definition中，我添加了一个新的构建步骤：“ cURL上传文件”。
一会儿玩了一下URL和可选参数的语法终于完成了它到达我的sftp服务器在正确的目标文件夹 - 到目前为止连接工作
但是当cURL尝试开始上传时，日志只会说：
curl: Can't open 'my-Subfolder/Another Subfolder/myfile.txt'!
curl: try 'curl --help' or 'curl --manual' for more information
Unexpected exitcode 26 returned by tool curl.exe
“buggy”是指在没有任何用户帮助的情况下在构建步骤的定义中选择文件的方式：
尝试1：我可以轻松地选择文件“... “ - 按钮 - 我可以浏览我的存储库的文件夹结构并选择一个文件。感觉很正常。然后该文件夹被写入文件框“文件” - 但没有双引号，虽然它包含空格...这会遇到错误，因为cURL确实不理解文件夹名称。
试试2：
然后我自己添加了双引号，但我仍然得到上面的错误。
试试3：
然后我尝试了语法**/myfile.txt
Ahaa，这实际上有效!!但是这会上传名为myfile.txt的所有文件夹中的所有文件（日志告诉我一些有趣的事情：使用带有大括号的另一种语法调用curl：{“complete-path / to /我的/文件名“}）
以防万一tfs-dev-team的人读到这个：另一个无意义的链接是步骤定义底部的“更多信息”。它导致了一个主题“部署：Azure PowerShell” - 与FTP上传无关，它的内容只是“这个主题尚未编写......”： - （
所以，我最终得到了以下可能性：
1。使用语法**/filename（如果你可以忍受将上传具有相同文件名的repo的所有子文件夹中的所有文件的缺点，那么最好保持文件名的唯一性！）
2. 之前使用另一个构建步骤并将文件复制或移动到repo的根文件夹中，以便仅在没有路径信息的“Files”-TextBox中使用文件名。
3。忘记cURL-build-steps：将WinSCP与临时脚本一起使用并使用批处理脚本步骤（http://winscp.net/eng/docs/guide_automation）运行： - ）
（上面提到的带有大括号的语法对我来说没用，因为它迫使我包含构建代理的整个路径，我不能在我的repo中使用相对路径。）
任何更好的想法？
答案 0 :(得分：0)
我可以使用TFS 2015 update1 + curl 7.47.0重现您的方案：
如果文件夹中包含空格，例如您的方案中的Another Subfolder，则curl无法识别它，我们会收到错误：curl: Can't open 'C:/agent/_work/xx/s/Another'!
如果我们使用语法** / myfile.txt，我们将获取工作空间中名为myfile.txt的所有文件。
但是如果我们将文件放在名称不包含空格的文件夹下，我们就不会收到错误curl: Can't open 'C:/agent/_work/xx/s/Another'!，因此您可以考虑创建一个新文件夹，例如{{1}并且需要将文件复制到此文件夹下，然后您可以使用整个路径。