Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce number of package sources (feeds) for our builds [and declare in a single location] #8019

Closed
Tracked by #8062
MiYanni opened this issue Mar 30, 2022 · 3 comments · Fixed by #8285
Closed
Tracked by #8062
Assignees
Labels
Area-Infrastructure Relates to build, test & run infrastructure of this repo. Resolution-Fixed The bug has been fixed, refer to the milestone to see in which release it was fixed. Triage-Investigate Reviewed and investigation needed by dev team
Milestone

Comments

@MiYanni
Copy link
Member

MiYanni commented Mar 30, 2022

Currently, we rely on multiple packages sources (Azure DevOps feeds) to acquire the components we need to build our product.

From NuGet.config:

<add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
<add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
<add key="dotnet5" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json" />
<add key="dotnet-public" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json" />
<add key="vssdk" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/vssdk/nuget/v3/index.json" />
<add key="vs-impl" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-impl/nuget/v3/index.json" />
<add key="myget-legacy" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/myget-legacy/nuget/v3/index.json" />

From Packages.targets:

https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-impl/nuget/v3/index.json;
https://pkgs.dev.azure.com/azure-public/vside/_packaging/vssdk/nuget/v3/index.json;
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json;
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json;
https://pkgs.dev.azure.com/dnceng/public/_packaging/myget-legacy/nuget/v3/index.json;
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json;
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json;
https://pkgs.dev.azure.com/dnceng/public/_packaging/nuget-build/nuget/v3/index.json;

However, all of these are not required. I manually investigated the contents of several of these and certain components/packages are published into multiple feeds.

A simple example is our own product. It gets published to multiple feeds because of the tools used. Our main feed (the one we directly publish to) is this one:
https://dev.azure.com/DevDiv/DevDiv/_artifacts/feed/VS/NuGet/Microsoft.VisualStudio.ProjectSystem.Managed/17.2.0-beta1-20330-02/overview

However, there is a Cloud Build agent that republishes the same package to this other feed a few minutes later:
https://devdiv.visualstudio.com/DevDiv/_artifacts/feed/VS-CoreXtFeeds/NuGet/Microsoft.VisualStudio.ProjectSystem.Managed.VS/17.2.0-beta1-20330-01/overview

My belief is that we are over-feeding since we aren't certain where each package should come from. So, we just added a bunch of them and let restoration sort it out. Instead, I'd like to minimize our reliance on so many feeds by identifying which package should come from which feeds and only having those feeds contained within our build. We should also investigate why we need two places to declare feeds. My belief is that we don't need to specify the list of package sources in two locations, and it was done as a work-around for some specific authentication/restore issue. But that would also need to be investigated and resolved here.

@MiYanni MiYanni added the Area-Infrastructure Relates to build, test & run infrastructure of this repo. label Mar 30, 2022
@kvenkatrajan kvenkatrajan modified the milestones: 17.4, 17.x Apr 7, 2022
@kvenkatrajan kvenkatrajan added the Triage-Investigate Reviewed and investigation needed by dev team label Apr 7, 2022
@MiYanni
Copy link
Member Author

MiYanni commented Apr 8, 2022

I may have found a simple solution. There seems to be an 'aggregate feed'. It would be worth looking at other repos to find if they utilize it. https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/Incident-help-for-Substitution-attack-risk-from-multiple-package-feeds?anchor=devdiv-common-feeds

MiYanni added a commit that referenced this issue Jun 10, 2022
…xed build as SwixBuild package is needed (accessed via file path). Modified some package versions to match latest of what is available in some specific feed situations. Removed non-multi-referenced variables in Versions.props. Removed MediaRecorder usage for the Integration tests as we currently don't run them anyway, which allowed the myget-legacy feed to be removed. Commented on what the purpose of some feeds are.
@MiYanni
Copy link
Member Author

MiYanni commented Jun 14, 2022

I have learned that these kind of aggregate feeds are required for projects in the VS repo. Closed-source projects require only a single package feed, which is why they are used. Public feeds cannot have upstream sources. Thus, you cannot make a public aggregate feed. Private aggregate feeds can have public upstream sources, though. For our repo, we need all public feeds, so the best option is simply to find the smallest subset of public feeds to use.

@MiYanni
Copy link
Member Author

MiYanni commented Jul 15, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Infrastructure Relates to build, test & run infrastructure of this repo. Resolution-Fixed The bug has been fixed, refer to the milestone to see in which release it was fixed. Triage-Investigate Reviewed and investigation needed by dev team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants