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

Support sourceUri passed on nuget restore/install and dotnet restore or RestoreSources set for msbuild /t:restore command, nuget restore #4214

Merged
merged 28 commits into from
Aug 27, 2021

Conversation

erdembayar
Copy link
Contributor

@erdembayar erdembayar commented Aug 22, 2021

Bug

Partially Fixes: NuGet/Home#10948
Fixes: NuGet/Home#10961

Regression? Last working version: n/a

Description

Users can pass sources with -source option to the restore/install command. It happens to be -source support already works for package namespace without any code change due to previous code change, so I added unit tests to assert them, only product change made here is made for nuget.exe install and nuget.exe install -source scenario.
Following scenarios are included here:

nuget.exe restore -source
RestoreSources in csproj for PackageReference (msbuild/t:restore, nuget restore)
nuget.exe install -source
dotnet.exe restore -source
PMC install-package -source
PMC update-package -source

Following is not implemented, because NuGet/Home#11035 is not complete yet, so I created follow up NuGet/Home#11140.
dotnet add package -source

Also this PR addresses nuget install scenarios not covered by previous PRs(nuget restore).

nuget install packages.config
nuget install Contoso --Version 1.0.0

Currently this PR contains commits for #4212.

PR Checklist

  • PR has a meaningful title

  • PR has a linked issue.

  • Described changes

  • Tests

    • Automated tests added
    • OR
    • Test exception
    • OR
    • N/A
  • Documentation

    • Documentation PR or issue filled
    • OR
    • N/A

@erdembayar erdembayar marked this pull request as ready for review August 22, 2021 16:17
@erdembayar erdembayar requested a review from a team as a code owner August 22, 2021 16:17
@erdembayar erdembayar requested a review from nkolev92 August 24, 2021 00:31
Copy link
Member

@nkolev92 nkolev92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

A few questions about the coverage.

I hope that we can simplify/shorten the tests though.

@@ -326,6 +326,296 @@ function Test-VsPackageInstallerServices-PackageNamespaceInstall-WithMultipleFee
}
}

function Test-PackageNamespaceInstall_Succeed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

naming: Please add the project style in the name.

Why do we need this test here? Wasn't it covered in some previous work items?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I added project type "PC" into all of them. I chosen PC over PackagesConfig otherwise some test name would be very long.
It looks I didn't add 'PMC install' tests into End2end test previously, but I did add Apex tests with #4150

test/EndToEnd/tests/PackageNameSpaceTests.ps1 Outdated Show resolved Hide resolved
test/EndToEnd/tests/PackageNameSpaceTests.ps1 Outdated Show resolved Hide resolved
test/EndToEnd/tests/PackageNameSpaceTests.ps1 Outdated Show resolved Hide resolved
Remove-Item $nugetConfigPath
}
}

# Create a custom test package
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no package installation tests for PR here, is that on purpose?

Now that I've gone through it all in detail, I see that you had a baseline for installation and -Source for installation.

Note that -Source is not supported in PackageReference

Copy link
Contributor Author

@erdembayar erdembayar Aug 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe PMC install for PR is synonymous with dotnet add package -source, but it's not implemented yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe PMC install for PR is synonymous with dotnet add package -source, but it's not implemented yet.

They are not equivalent.

Sources are ignored in PMC commands, there's a warning that gets logged when you try it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I'm not really suggesting we should add tests here.
I'm trying to provide as much context as possible to you, so that you can make sure you've covered all scenarios.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created follow up issue for this. NuGet/Home#11187

@erdembayar erdembayar force-pushed the dev-eryondon-SourceUri5 branch from 15d635c to 2f48afd Compare August 24, 2021 21:36
@erdembayar erdembayar requested a review from nkolev92 August 25, 2021 02:27
@erdembayar
Copy link
Contributor Author

@nkolev92 @kartheekp-ms
Please review.

Copy link
Member

@nkolev92 nkolev92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some test feedback, but looks great overall.

test/EndToEnd/tests/PackageNameSpaceTests.ps1 Outdated Show resolved Hide resolved
Remove-Item $nugetConfigPath
}
}

# Create a custom test package
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe PMC install for PR is synonymous with dotnet add package -source, but it's not implemented yet.

They are not equivalent.

Sources are ignored in PMC commands, there's a warning that gets logged when you try it.

Remove-Item $nugetConfigPath
}
}

# Create a custom test package
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I'm not really suggesting we should add tests here.
I'm trying to provide as much context as possible to you, so that you can make sure you've covered all scenarios.

@@ -10854,6 +10854,191 @@ public async Task RestoreNetCore_WhenPackageNamespacesConfiguredAndNoMatchingSou
Assert.Contains($"Installed {packageY} {version} from {pathContext.PackageSource}", result.AllOutput);
}

[Fact]
public async Task RestoreCommand_NameSpaceFilter_PR_WithAllRestoreSources_Properies_Succeed()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that I understand well enough what SimpleTestPathContext does, I feel like we could have benefited from an addition to modify that particular nuget.config, instead of adding a new one.

Quite often I think that the global packages folder of the user is getting polluted, forgetting that we are relying on having multiple sources.

Just something to consider. We can extend SimpleTestPathContext when appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants