Publish Test Results task failing - The specified path, file name, or both are too long.

[charliedavison]

I'm trying to use the Publish Test Results task to read my JUnit xml files into the build report.

However it currently fails claiming "The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."

The XML files are placed directly in the build path by my testing tools, and I'm passing as the test results file parameter.

$(Build.Repository.LocalPath)\TESTS-*.xml

The full path of the directory used for the build is -

C:\Agent_work\5\s\

So quite easily less than 260 characters!

My build agent is running on an Azure virtual machine(Windows 2012 R2).

Can anyone shine any light on what might be going on?

[kaadhina]

Can you please send the build logs to [email protected] so that we can take a look at this

[ericsciple]

FYI - It looks like the ps1 implementation uses the old PowerShell handler and corresponding closed-source task lib. The issue is that Find-Files scans the full directory and then applies pattern on top of the results. Find-Files has been fixed to handle long paths in the open source task lib https://github.com/Microsoft/vsts-task-lib/tree/master/powershell/Docs for the PowerShell3 handler.

Alternatively porting the task to fully use the nodejs lib would solve the issue as well. I see a js implementation exists for non-Windows platforms.

[charliedavison]

Hi @kaadhina, sorry for the delay in responding, I must have missed this. I've emailed the build logs over to you as requested however I received a "Sender not allowed" response back.

@ericsciple, you're right that the issue seems to be with Find-Files. I am currently working around the the problem by replacing Find-Files with Get-ChildItem on line 40 of PublishTestResults.ps1 which seems to resolve the issue in my case.

[damienpontifex]

@nigurr was this closed as it's resolved? Still getting this in my Publish Test Results step today...

[nigurr]

It's not fixed for Windows Agent, however you can use Xplat agent for the same. Upcoming new core-clr agent will fix this issue

[damienpontifex]

Ok great. Will keep my eye out for it.

Thanks @nigurr

[ericsciple]

@nigurr The Core CLR agent will not fix the issue. It will run the same tasks. Two ways to fix it:

1. update the ps implementation of the task to use the new ps lib.
   OR 2) drop the ps implementation altogether and only expose the nodejs implementation.

[ericsciple]

@damienpontifex fyi it's under developement @ https://github.com/Microsoft/vsts-agent and we're going to have a preview version available for Windows very soon. A preview version for OSX/Linux is available today.

[bryanmacfarlane]

Assigning to @nigurr

We should fix. Option #1 from Eric is the best option. It has to happen since the other handler is being deprecated.

1. update the ps implementation of the task to use the new ps lib.

[nigurr]

Since this is moved to NodeJS implementation with next sprint. I am closing this issue. It shouldn't be issue from next update.