Merge remote-tracking branch 'origin/release/2.1' #1800
Conversation
…t vs binary and which must have crlf (sln) vs lf (sh)
…ts in the test output folder
Moving to the repo toolset.
* Making the 'RestoreSources' configurable. * Move 'RestoreSources' into Common.props * Removing the 'RestoreSources' from the test assets. * Removing the 'RestoreSources' from all project files. * Adding back a truncated NuGet.config * Moving 'RestoreSources' into its own props file. * Fixed one test: Microsoft.NET.Publish.Tests.GivenThatWeWantToStoreAProjectWithDependencies.store_nativeonlyassets * Fixed one test: Microsoft.NET.Publish.Tests.GivenThatWeWantToStoreAProjectWithDependencies.store_nativeonlyassets - adding the correct NuGet source. * Ensuring that tests use a 'Test' NuGet.config as the root NuGet.config no longer supplies the test with feed information.
* Updating the SDK feeds. * Adding back: "https://api.nuget.org/v3/index.json" to the 'test' NuGet.config * Correcting the 'BlobFeed' URL.
Update feed tasks version
…15.5-20171130-080041 Merge release/2.0.0 to release/15.5
Merging dev/release/2.0 into release/2.0.0
|
Running jobs with the updated netci in Jenkins currently. Will update once passing. |
|
Windows jobs are failing due to a max path issue. I've pinged @mmitche about updating the images to enable long path support so that ZIP extraction doesn't fail in PowerShell (and so that long path opt-in functions elsewhere as well). |
|
I've enabled this in win2016-base to see what happens. IMO though, the the base path is already pretty short and we shouldn't be relying on a non-default feature to make the CI work. The target path has a bunch of elements in it that could probably be shorted: D:\j\workspace\debug_windows_nt8a96f9d2*artifacts.dotnet**2.2.0-preview1-007460*\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.transport.abstractions\2.1.0-preview1-26623\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.dll |
The path I gave is just one such example. There are other files in the ZIP which are just as long (possibly longer) and it is a continued risk moving forward (as more packages are placed in the SDK store, etc). So shortening the path may not fix the issue and even then, may only fix it temporarily. Indeed, this only became a problem in this PR because additional dependencies were put in the ZIP (in 2.2) that extended the path past the previous max. Enabling long paths prevents the needs for CI specific hacks/workarounds (such as using the explicit long path syntax or extracting to the root drive and then moving it to the correct location with robocopy). |
|
But that also means the build process cannot work ever on Win2012, or on any developer machine that doesn't have long paths enabled. That's why I'm skeptical. |
|
I think that is a more general problem and one that is going to be hit more and more frequently moving forward. There are already very few [dotnet] repos for which I can enlist, restore, build, test, and then clean today (from the default enlistment directory VS sets up -- This is consistently only an issue in Windows (as the other systems don't have such limitations) and is generally worked around by moving the enlistment directory on the box or relying on some tool having opted-into long path support. |
No description provided.