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

Install manifests for rollback after update --from-rollback-file #37965

Merged

Conversation

Forgind
Copy link
Member

@Forgind Forgind commented Jan 12, 2024

Fixes #37958 for 1xx

Description
Manifest updates were disabled for Install if the user had previously updated --from-rollback-file, as that clearly indicates they wanted to pin to a specific set of versions, but that did not take into consideration if a user wanted to install --from-rollback-file, which similarly indicates they want a specific version but a different specific version. This takes that into account.

Customer Impact
Customers who called dotnet workload update --from-rollback-file <file> then dotnet workload install --from-rollback-file <file> would have the second command not install the desired versions.

Regression?
Yes. The decision to update or not update is made based on the install state file that was only added in 8.0.1xx.

Risk
Low

Tests
TBD

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Jan 12, 2024
@Forgind Forgind added Servicing-consider and removed untriaged Request triage from a team member labels Jan 12, 2024
@Forgind Forgind added this to the 8.0.1xx milestone Jan 12, 2024
@@ -134,7 +134,7 @@ public void InstallWorkloads(IEnumerable<WorkloadId> workloadIds, bool skipManif
if (!skipManifestUpdate)
{
var installStateFilePath = Path.Combine(WorkloadInstallType.GetInstallStateFolder(_sdkFeatureBand, _dotnetPath), "default.json");
if (File.Exists(installStateFilePath))
Copy link
Member

Choose a reason for hiding this comment

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

I'm wondering why we don't move line 160 up to 132 and just use "!useRollback" here? Seems like the code may have been trying to save the isnull check but I can't imagine that's a slow check.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah; I can do that. I typically try to change as little as possible for servicing changes, but that shouldn't hurt anything.

Copy link
Member

Choose a reason for hiding this comment

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

Just take note that on line 168, the default useRollback value is passed through and may not have been set based on if the skipManifestUpdate option that controls the conditional block on line 145.

Copy link
Member Author

Choose a reason for hiding this comment

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

joeloff is right, and in particular, deciding to skip the manifest update isn't decided yet on line 132.

The useRollback parameter passed into InstallWorkloadsWithInstallRecord is only used to modify the install state. If we legitimately rolled back to a specific set of manifests, it is created with those manifests. If not, it is deleted (in 8.0.1xx). Moving useRollback up may make it create the install state when it didn't update manifests at all, much less from a rollback file.

@Forgind Forgind merged commit 017bf88 into dotnet:release/8.0.1xx Jan 16, 2024
16 checks passed
@Forgind Forgind deleted the install-manifests-for-rollback branch January 16, 2024 21:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants