Closed jnm2 closed 4 years ago
Workaround:
# Workaround for https://github.com/codecov/codecov-exe/issues/71
$codecovFullPath = Join-Path (Get-Location) $codecov
Push-Location $testResultsDir
& $codecovFullPath --name $tfm --file coverage.$tfm.xml --token $env:CODECOV_TOKEN
# Workaround for https://github.com/codecov/codecov-exe/issues/71
Pop-Location
Unfortunately this is a limitation of the command parsing library being used, and how it has been set up. CommandLineParser While I am not 100% sure, I do believe the following needs to be used to get around it:
$testResultsDir = 'artifacts\Test results'
codecov --name $tfm --file "'$testResultsDir\coverage.$tfm.xml'" --token $env:CODECOV_TOKEN
(Notice the single quotes used after and before the double quote).
codecov --file "artifacts\Test results\a.xml" "artifacts\Test results\b.xml"
Passing multiple file paths this way is not supported unfortunately, all paths are expected to be within a singe quote string, using either single or double quotes.
IE:
codecov --file '"artifacts\Test results\a.xml" "artifacts\Test results\b.xml"'
Or
codecov --file "'artifacts\Test results\a.xml' 'artifacts\Test results\b.xml'"
(Again, I am not 100% certain it works with spaces).
If the mentioned ways do not work, then I am afraid that this won't be fixed until v 2.0 of codecov-exe (where I plan a major overhaul of the program, and changing how the arguments get parsed, changing the argument parser, changing the arguments to be similar but not exactly the same as the codecov bash script).
Thanks.
--file "'$testResultsDir\coverage.$tfm.xml'"
has the same result as without the single quotes.
I was almost afraid of that. Most likely in is the result of the separator used on the argument attribute (https://github.com/codecov/codecov-exe/blob/master/Source/Codecov/Program/CommandLineOptions.cs#L74).
I will investigate and see if this is something we are able to handle with the current library used, and without a breaking change.
Unfortunately I have not been able to figure out how to fix this in a non-breaking way, as such I am afraid that this will not be fixed until the next major version have been released (which I have not yet started working on).
I will add a new section to the readme for Known Issues with a reference to this issue.
Thanks for looking and for the tool! I appreciate both.
Not a problem.
You should actually thank @larzw for the tool. While I am the one maintaining the tool now, he was the one that created it and most of the codebase is his work.
Thanks @larzw! 😊
Semi-related, have you seen https://github.com/dotnet/command-line-api/wiki/DragonFruit-overview?
No I had not, but I will make a note of it before deciding which parser to change to.
I was actually thinking of changing to Spectre.Cli, which have most of the features I want (and some others in the planning stage).
I have been looking into this issue a little more, and it actually turns out that it isn't a limitation with the commandline parser, but rather something we had done wrong while using it instead.
I have a fix ready, but not sure if I will be pushing it today or not (as I have already pushed 2 versions today, and want to wait a little in case those introduced other issues).
:tada: This issue has been resolved in version 1.11.2 :tada:
The release is available on:
Your friendly GitReleaseManager bot :package::rocket:
Woot cheers!
Using 1.5.0
It should respect quotes by using the string[] args that dotnet passes to Program.Main.
With this hypothetical call:
Program.Main will receive this as args:
Given such arguments, the files collection should contain
artifacts\Test results\a.xml
andartifacts\Test results\b.xml
, notartifacts\Test
,results\a.xml
,artifacts\Test
,results\b.xml
.