Properly set the nuget cache for the repo #24505
Conversation
|
Confirmed |
|
I believe the failure for CoreFX is from the following:
<!-- This dependency should be added, but it causes the github PR legs to not launch. -->
<!-- Dependency Name="microsoft.dotnet.build.tasks.feed" Version="2.2.0-beta.19229.8">
<Uri>https://github.com/dotnet/arcade</Uri>
<Sha>a7a250e9c13147134543c35fef2fb81f19592edf</Sha>
</Dependency--> |
|
@RussKeldorph I have no idea why the CoreFX leg is failing. I tried uncommenting the XML mentioned above to not effect and attempted to bump the version number, also no observed impact. Any suggestions on who can help with this facet of the pipeline? |
|
@AaronRobinsonMSFT That's indeed the error, however the XML file is just for information. Add the following property to <MicrosoftDotNetBuildTasksFeedVersion>2.2.0-beta.19229.8</MicrosoftDotNetBuildTasksFeedVersion> |
|
@hoyosjs I guess the extension is supposed to indicate that? I updated both files with the suggested version and resolved some conflicts. Thanks for the suggestion. |
|
@hoyosjs The set version is now being respected during discovery - yay, but the package for some reason isn't being pulled down. Any thoughts here? |
|
Taking a look now |
|
I think I found the issue: we just never call the common engineering files to perform restore properly |
|
Yeah, I'm seeing the missing package being restored to the wrong place. The different steps don't agree on the package root. |
I don't understand how this was ever working then. I want to understand what we are missing in a bit more detail. Any links to relevant doc or code that illustrates the missing call? |
|
I'm honestly not sure how this fixes SourceLink entirely, although I have a good guess. As for how this used to work, no idea. I left the comment of the package restore missing on the review for CoreFX testing. I assumed some part of the restore logic in arcade had run at an earlier step. Try adding this in between Build tests and Send tests to Helix steps in - ${{ if eq(parameters.corefxTests, true) }}:
- ${{ if ne(parameters.osGroup, 'Windows_NT') }}:
- script: eng/common/build.sh -restore -configuration:$(buildConfig) -warnaserror:0 /p:ArcadeBuild=true -projects $(Build.SourcesDirectory)\eng\empty.proj
displayName: Build product
- ${{ if eq(parameters.osGroup, 'Windows_NT') }}:
- script: powershell eng\common\build.ps1 -restore -configuration:$(buildConfig) -warnaserror:0 /p:ArcadeBuild=true -projects $(Build.SourcesDirectory)\eng\empty.proj |
@AaronRobinsonMSFT I don't think anyone does at this point. We should just try to increase our understanding each time we find these, and try to prevent others from tripping over the same thing. The proliferation of |
|
Yay! Confirmed the package not being found in the CoreFX leg has been addressed. +1 for progress. |
|
The CoreFX leg passed! 😂 |
|
Looks like the restore happened in coreclr/eng/send-to-helix-step.yml Lines 21 to 27 in b8f9262  :
|
|
Docker image timeout. All other legs pass as expected. Results will be available from https://mc.dot.net/#/user/coreclr-ci/pr~2Fdotnet~2Fcoreclr~2Frefs~2Fpull~2F24505~2Fmerge/test~2Ffunctional~2Fcli~2F/20190510.722 Details from Job 58aa7264-c462-4d24-a226-809c97b88b62 |
|
arm64 failure is dotnet/core-eng#6295 |
* Properly set the nuget cache for the repo * Change coreclr NuGet package cache from "./packages" to "./.packages" Commit migrated from dotnet/coreclr@44d22bd
cc @RussKeldorph @sbomer @jkoritzinsky