-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
Pipelines should validate upgrade scenario #109059
Labels
Issue-Feature
Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Milestone
Comments
mdanish-kh
added
the
Issue-Feature
Complex enough to require an in depth planning process and actual budgeted, scheduled work.
label
Jun 6, 2023
microsoft-github-policy-service
bot
added
the
Needs-Triage
This work item needs to be triaged by a member of the core team.
label
Jun 6, 2023
Ah, I did feel an issue like this would've already existed but couldn't find it under
Area-Validation-Pipeline
|
microsoft-github-policy-service
bot
removed
the
Needs-Triage
This work item needs to be triaged by a member of the core team.
label
Jun 6, 2023
Reopen with reason: Testing trigger; |
Close with reason: It worked; |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Issue-Feature
Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Description of the new feature/enhancement
Some packages may be perfectly fine for a clean install but may not work as well in the upgrade scenario. An example of such a package is
Anki.Anki
(#109046) that does not have a silent upgrade flow. Validation Pipelines should check if the package works as intended in the upgrade scenario as well. This may include but not limited to detecting if the upgrade is silent, whether it requests for a reboot or throws a non-zero error code (which may mean we need InstallerSuccessCodes added in the manifest). Once #13620 is resolved, the upgrade validation should also check whether the Registry entries are updated as intended.Proposed technical implementation details (optional)
winget show <PackageId> --versions
or fromGet-WinGetPackage -Id <PackageId> | Select AvailableVersions
from the PowerShell moduleEdge cases include the Installer Url of the previous package no longer works, or the package uses a vanity URL. These should not be considered for the upgrade validation.
Ideally, the upgrade validation should be carried out in a fresh environment/VM. However, if this incurs significant resource costs, it may be feasible to carry out the validation within the same environment. In such cases, a mechanism to clean all versions and registry entries before the next validation step (install or upgrade) should be implemented as there could be packages that don't allow downgrades or install side-by-side.
The text was updated successfully, but these errors were encountered: