align dotnet nuget sign verbosity with that of nuget.exe

[heng-liu]

Bug

Fixes: NuGet/Home#11173

Regression? Last working version:

Description

For NuGet.exe sign command, if the package is signed successfully, the default verbosity will show the following info:

C:\demo> nuget sign .\test1.nupkg -CertificatePath .\1A0BA119ABDE3BC428A15672ECF8CD31B4725A6D.pfx -CertificatePassword password -Timestamper http://timestamp.entrust.net/TSS/RFC3161sha2TS -OutputDirectory .\package\Signed\


Signing package(s) with certificate:
  Subject Name: CN=Test certificate for testing NuGet package signing
  SHA1 hash: 1A0BA119ABDE3BC428A15672ECF8CD31B4725A6D
  SHA256 hash: 54D4139CC924A50E8851C1B2ACAFECB09D7C48E927778C1F325B59DEE6272BBB
  Issued by: CN=Test certificate for testing NuGet package signing
  Valid from: 8/27/2021 10:19:48 AM to 8/28/2021 10:19:48 AM

Timestamping package(s) with:
http://timestamp.entrust.net/TSS/RFC3161sha2TS
Signed package(s) output path:
.\package\Signed\
Package(s) signed successfully.

Before this change, dotnet nuget sign has no output in default verbosity level if it's signed successfully.
After this change, dotnet nuget sign has the same output as following:

C:\demo> .\PatchedSDK\dotnet.exe nuget sign .\test1.nupkg --certificate-path .\1A0BA119ABDE3BC428A15672ECF8CD31B4725A6D.pfx --certificate-password password --timestamper http://timestamp.entrust.net/TSS/RFC3161sha2TS --output .\package\Signed\

Signing package(s) with certificate:
  Subject Name: CN=Test certificate for testing NuGet package signing
  SHA1 hash: 1A0BA119ABDE3BC428A15672ECF8CD31B4725A6D
  SHA256 hash: 54D4139CC924A50E8851C1B2ACAFECB09D7C48E927778C1F325B59DEE6272BBB
  Issued by: CN=Test certificate for testing NuGet package signing
  Valid from: 8/27/2021 10:19:48 AM to 8/28/2021 10:19:48 AM
Timestamping package(s) with:
http://timestamp.entrust.net/TSS/RFC3161sha2TS
Signed package(s) output path:
.\package\Signed\
Package(s) signed successfully.

In this PR:
1.Make the verbosity of dotnet nuget sign command align with NuGet.exe sign command.
2.Add assertion of those messages in tests.

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]

@heng-liu
Could you be able to include full output log from dotnet nuget sign command after your change?

[heng-liu]

@heng-liu
Could you be able to include full output log from dotnet nuget sign command after your change?

Thanks for reviewing! Added output log from dotnet nuget sign command in the description.

[ghost]

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

[zivkan]

Has the output been validated both with our PM, but also the .NET CLI PMs? I don't think we should "align dotnet nuget * with nuget.exe output". Consider for example default "msbuild -t:build" to "dotnet build" or "msbuild -t:restore" and "dotnet restore" output. The dotnet cli commands are intentionally less verbose to be more clear to customers.

In particular, I don't think that outputting the certificate information, timestamp information, or output path is useful at default verbosity. It seems like good information to output at detailed verbosity, but not at normal or minimal verbosity.

[ghost]

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

[heng-liu]

Has the output been validated both with our PM, but also the .NET CLI PMs? I don't think we should "align dotnet nuget * with nuget.exe output". Consider for example default "msbuild -t:build" to "dotnet build" or "msbuild -t:restore" and "dotnet restore" output. The dotnet cli commands are intentionally less verbose to be more clear to customers.

In particular, I don't think that outputting the certificate information, timestamp information, or output path is useful at default verbosity. It seems like good information to output at detailed verbosity, but not at normal or minimal verbosity.

Sorry for the late response.
I'll start with a mini spec and send the spec to both NuGet PM and .NET CLI PM and see what do they suggest.
Thank you for the great suggestion! @zivkan