I am trying to run nunit tests in azure test plan by triggering Release build pipelines. I have observed file attachments with greater than 255 characters are not attached to the test report.
Using below code to attach reports TestContext.AddTestAttachment(string path) (comes with nunit package).There is no exception thrown in logs, but just a warning message as below:
Failed to upload result logs to Log store, trying to upload to file service.
File at location is not available on the disk.
Need help on how to attach the file with long paths to the test attachments.
Note: Concerned file is available in the path
The limitation is existed that windows file paths is not longer than 255 characters in Azure test plan.
You could copy or move the files out of the folder into another folder that won't violate the limit. For example, using this Copy Files task to copy file attachments from a source folder to a target folder using match patterns.
Related
What is the proper way of delivering temporary build-time assets using nuget?
I am making a nuget package with a single file, which dependent projects require during the build phase. I would like the content of the file to be copied to obj\$(Configuration) folder inside a dependent project before proceeding with the rest of the build. Of course, the obj folder is temporary, so I would like my file to be copied there again as part of the next build if obj gets cleared out.
I tried contentFiles approach described here. This takes care of packaging my file inside nupkg file, but I was unable to set it up so that my file gets delivered (and re-delivered) to obj\$(Configuration).
You're looking for NuGet's MSBuild extensibility. Unfortunately it means you'll need to learn a bit about MSBuild if you don't already know it. I recommend running msbuild -bl or dotnet build -bl, which will create a msbuild.binlog file, which you can view with the msbuild structured log viewer.
One option is to have a target that creates the file in the intermediate output directory at an appropriate time (probably need to use BeforeTargets). You could use the Inputs and Outputs attributes to have msbuild do incremental build checks and skip copying when it doesn't need to, possibly making the build a little faster.
However, unless the file is has dynmanic content, copying the file is a waste. it's just going to be included as an item in another part of the build process. So, if it's static content, you could just create the relevant item in your targets file from your package's extracted directory, and then it's just as good as if it was copied to the intermediate output directory, without wasted time and duplicated disk space.
i'm getting
##[error]Error: File entry unexpectedly large: 38749 (max: 4096)
when try to deploy using azure web app
Please refer to this wiki:
But, Web packages created using MSBuild task (with default arguments)
has a nested folder structure that can only be deployed correctly by
Web Deploy. If Run From Package is used for the above packages, the
web package would be copied without honoring the nested folder
structure and can cause runtime issues.
For if you want to deploy the package which generated from MSBuild / VSBuild, please try with executing Archive files task after MSBuild / VSBuild task. So that the file which has a nested folder structure can be deployed with Web app deploy task correctly.
So far i solve my problem by downsize the actual project size by deleting old files i think the project should be less then 2GB as mentioned here
I'm attempting to run a "Windows Machine File Copy" task in a deploy step on VSTS via private Agent.
In reading the documentation at https://learn.microsoft.com/en-us/vsts/build-release/tasks/deploy/windows-machine-file-copy?view=vsts, the section for "Source" parameter says:
You can use pre-defined system variables such as $(Build.Repository.LocalPath) (the working folder on the agent computer), which makes it easy to specify the location of the build artifacts on the computer that hosts the automation agent.
When I attempt to use that exact variable (because I literally want to copy the most recent source files) as such:
I get the following error when running the task:
[error]Source path 'C:\agent_work\r1\a\$(Build.Repository.LocalPath)' does not exist.
2018-04-18T05:52:09.2461155Z ==============================================================================
2018-04-18T05:52:09.2461984Z Task : Windows Machine File Copy
2018-04-18T05:52:09.2462630Z Description : Copy files to remote machine(s)
2018-04-18T05:52:09.2463336Z Version : 2.0.4
2018-04-18T05:52:09.2463945Z Author : Microsoft Corporation
2018-04-18T05:52:09.2464620Z Help : [More Information](https://go.microsoft.com/fwlink/?linkid=627415)
2018-04-18T05:52:09.2465332Z ==============================================================================
2018-04-18T05:52:13.1043515Z ##[error]Source path 'C:\agent\_work\r1\a\$(Build.Repository.LocalPath)' does not exist.
2018-04-18T05:52:13.1533941Z ##[section]Finishing: Copy files To Server
2018-04-18T05:52:13.1653576Z ##[section]Finishing: Release
Am I missing something?
For background, I want to do this Robocopy/WMFC because I'm deploying a static website that's around 40gigs total in source. I don't want to copy the entire Build Output to the artifacts directory first, because it will take too long. I need quicker deploys than copying 40 gigs of data. This is a legacy site and there isn't much I can do about the way it's structured.
Ultimately, I'm trying to pull the latest source (without clean, because pulling 40 gigs is too slow) and then do a RoboCopy /MIRror to copy only changed files to the destination IIS directory on another machine.
I can see on your question that you are doing this on a release, based on C:\agent_work\r1\a\$(Build.Repository.LocalPath), where r1 is a release.
Based on the release variable documentation, the $(Build.Repository.LocalPath) is not available for a release.
You should use one of the release variables instead, like $(System.DefaultWorkingDirectory)\the artifact name
I am using NAnt to build an asp.net mvc 3 project that contains EXT JS. After the code successfully compiles, msbuild attempts to copy the files into the following sub folder "_PublishedWebsites". Unfortunately the build fails and I get the following error:
[msbuild] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(177,5):
error MSB3021: Unable to copy file "Scripts\Foobar\extjs\resources\css\ext-all-gray.css" to "build\_PublishedWebsites\Foobar.WebUI\Scripts\Foobar\extjs\resources\css\ext-all-gray.css".
Could not find a part of the path 'Scripts\Foobar\extjs\resources\css\ext-all-gray.css'. [C:\Work\Projects\Foobar\Src\Foobar.WebUI\Foobar.WebUI.csproj]
The files are in the location but the error seems to occur when files have "-" in the name. To confirm this I excluded the files that were causing the build to fail and what do you know, the build works.Any suggestions would be appreciated.
This error message is about output location not input files, I guess. IMO your part of the output path "Scripts\Foobar\extjs\resources\css\" does not exist. Let's say if "css" folder is missing. Do you have some other .css files without '-' chars in resources\css folder? Are they deployed correctly?
We currently carry out development on a mapped drive. When I write nunit tests against a test assembly it will pick up the assembly, however does not recognise any of the tests.
If I move the solultion etc to a local drive and reference it again then everything works fine.
What I really woiuld like to know is why this is being caused, and how I can carry on using a network drive for development.
Per http://geekswithblogs.net/TimH/archive/2007/08/02/114340.aspx, NUnit apparently does not have appropriate permissions to access the assembly when on a network drive. The suggested fix is to add a post-build event to copy the assembly to a local temp directory and run NUnit off that copied assembly:
Within VS, open the project properties.
Go to the Build Events tab and enter the following 'Post-build event command line':
del /q c:\temp\nunit*.*
copy "$(TargetDir)." c:\temp\nunit
A potential issue you may have as a result of this change is related to the AppBase as per Unable to load <mytest> because it is not located under Appbase. The answer there is to update the Settings element within the .nunit file to include an app base of C:\Temp\NUnit then update the assembly element's path to remove any leading directory information.