Print the upgrade table during upgrade --all

[jedieaston]

• Have you signed the Contributor License Agreement?
• Are you working against an Issue?

---

Resolves #1858.

This PR changes the upgrade --all flow to print the table of available upgrades before running the upgrades, giving the user a more friendly list of upgrades (as opposed to several lines of Workflow::ReportManifestIdentityWithVersion).

I had to make a change to EnsurePackageAgreementsAcceptanceForMultipleInstallers, namely, that it now gets the manifest and checks to see if there are any agreements before printing anything. This is less efficient if there is an agreement, but since most packages don't have agreements right now, it shouldn't (on average) change performance. (Edit: this doesn't change performance really at all, see below).

I reused the upgrade table from winget upgrade for this too, if a different appearance would be better then I can make a new table. Speaking of appearance, I know that nobody from MS commented on that ticket, so if anyone thinks it is better the other way then I can close this.

Tested: manually.

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yao-msft]

This is less efficient if there is an agreement, but since most packages don't have agreements right now, it shouldn't (on average) change performance.
Actually, currently manifests with agreements will be blocked in winget-pkgs submission. But almost all packages from msstore source have agreements.

[yao-msft]

        hasPackageAgreements |= !showContext.Get<Execution::Data::Manifest>().CurrentLocalization.Get<AppInstaller::Manifest::Localization::Agreements>().empty();

nit: this could now be hasPackageAgreements |= true;

---

Refers to: src/AppInstallerCLICore/Workflows/InstallFlow.cpp:211 in 9111a03. [](commit_id = 9111a03, deletion_comment = False)

[JohnMcPMS]

This is less efficient if there is an agreement, but since most packages don't have agreements right now, it shouldn't (on average) change performance.

Actually, currently manifests with agreements will be blocked in winget-pkgs submission. But almost all packages from msstore source have agreements.

But since this manifest is coming from the context data, not being retrieved from a remote location, it isn't really a performance problem.

[yao-msft]

This is less efficient if there is an agreement, but since most packages don't have agreements right now, it shouldn't (on average) change performance.

Actually, currently manifests with agreements will be blocked in winget-pkgs submission. But almost all packages from msstore source have agreements.

But since this manifest is coming from the context data, not being retrieved from a remote location, it isn't really a performance problem.

I agree. And actually we were already doing the same check several lines below. Just trying to clarify where agreements are being used.

[jedieaston]

@JohnMcPMS Let me know which way you want to go on the table and I can make the adjustments. (I could go either way).

[JohnMcPMS]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[JohnMcPMS]

@JohnMcPMS John McPherson FTE Let me know which way you want to go on the table and I can make the adjustments. (I could go either way).

I don't feel strongly about it really. It seems like the only strong opinion is to keep it, so I think at this point it is winning. The good thing is this is early in 1.3, so we can get feedback and update if needed,

[JohnLukeBentley]

@JohnMcPMS thanks for letting the table through (on the basis you mention). And @jedieaston thanks for the coding!

[denelon]

I know the PowerShell cmdlets are still super early. @jedieaston have you had a chance to see if this is breaking for anything that was hacked together there? I think the table output might be problematic for the way we're calling upgrade today.

[jedieaston]

It looks like the Upgrade-WinGetPackage only upgrades a single package, so that isn't affected since this only shows the table on upgrade --all.