Closed cdacamar closed 6 years ago
Hi
I think the problem is the parameter value "chk, ret". In the newest version the approach of how they are handled has changed. The "," causes issues. I'll have a look later today how to fix it. As a workaround, is it possible to use something else then a comma?
The only issue with that workaround is that those parameters are processed as "Multipliers" in the VSTS build configuration. As far as I can tell VSTS always wants comma separated lists to properly give us parallelism. We could inject a translation phase but this option is not preferable if the bug can be easily fixed.
Yes I see. I will look into it as soon as possible. However that will take roundabout one day.
So since the new version from yesterday the parameters are supplied are treated a bit differently than before. So far the string supplied was just sent "as is" to the server. This was in so far a problem as you had to escape the string yourself so that it produces correct JSON format (thus as well the wrapping of the items in \"). In other cases, it was not possible to use the parameters at all because if you specified a Variable then you had no choice and could not escape the item yourself.
Therefore now the string supplied to the task is split up first by comma so we get a list of all key-value pairs and then by colon to really get the individual keys and values and then we can apply the proper stringification (as the parameter values even need double-stringification for some reason this was the best way of doing it). Sidenote: Now you don't need to put the \" around your items anymore.
Of course this now brings problems for when we use the comma as part of the value of a variable.
My proposal would be that it is solved as follows. Given the following string entered on the Task configuration: BuildConfiguration: chk,ret,BuildPlatform: x86,amd64,FileSpecification: CompilerAndLibraries
We will still split first by the comma, which will result in following items:
When looping through all these items it is splitted by the first occurence of the colon to identifiy each parameter key and value. As the second value will have no occurence of a colon it will fail at the moment. My proposal would be that i'll check the next values if they contain any colon, if they don't I will treat them as value of the previous item.
This means we would get:
I think this would cover 99% of the use cases. However you could still have a failing task if your value that is separated by a comma contains a colon as part of the value itself. For example if you would have the following:
FileLocations: C:\Test\MyDirectory, D:\Temp\HereIHaveAnotherDirectory
However I'm not sure if this is really needed at the moment. Maybe you can tell me if you have such a use case. In order to properly implement this I would need to change the separator characters from the Task, which would mean I would need to bump the version to 3.* as the API changes and previous configurations will not work as before.
What do you think, is the above mentioned solution acceptable or do you need anyway the one that works with having multiple paths as value of one parameter?
Looking over our build definitions I don't believe the split path problem will be an issue. We really only have commas in places that split up non-path configuration values. This should suit our needs :+1:
Allright, thanks for the quick feedback.
Then I will implement this solution and update the documentation accordingly.
I'll update you once the new version is uploaded.
@cdacamar
Version 2.6.2 is now available and includes a fix for your problem.
Please try it out and let me know if it worked or not :-)
Everything appears to be running smoothly. Thank you!
We have git branches like
prod/fe
. When trigger build is invoked it produces the following error: