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

Workload manifest updates #16891

Merged
merged 8 commits into from
Apr 30, 2021
Merged

Conversation

sfoslund
Copy link
Member

@sfoslund sfoslund commented Apr 13, 2021

No description provided.

@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@sfoslund sfoslund force-pushed the WorkloadManifestUpdates branch from 9a402f8 to b51159e Compare April 13, 2021 22:28
@wli3
Copy link

wli3 commented Apr 13, 2021

not done. But I should really finish my PR

@sfoslund
Copy link
Member Author

Addressed feedback I've received so far, waiting on workload teams to start generating manifest packages to test with.

@wli3
Copy link

wli3 commented Apr 16, 2021

do you mind to do a rebase in the meantime? It is easier to see the change. Thanks!

@sfoslund sfoslund force-pushed the WorkloadManifestUpdates branch from e32a73a to 0412aaa Compare April 16, 2021 17:31
Copy link
Member

@dsplaisted dsplaisted left a comment

Choose a reason for hiding this comment

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

So far I've just looked at the implementation, but not the test updates.

@sfoslund sfoslund force-pushed the WorkloadManifestUpdates branch from 0412aaa to c5440f5 Compare April 26, 2021 19:05
@sfoslund
Copy link
Member Author

@wli3 @dsplaisted I think I'm caught up to feedback now. I'm going to start testing end to end with the new manifest packages but in the meantime feel free to add more feedback.

@sfoslund
Copy link
Member Author

I've finished testing locally and I believe everything is good to go. A couple of notes:

  • Since workload teams have not started producing properly formatted packages I tested by creating my own and using a local package source. Ideally I'd like to test end to end with real packages before this is merged.
  • Manifest updates will only work for workloads that have properly formatted packages (id: {manifest id}.manifest-6.0.100, version matching manifest version, and workload manifest/targets in a data directory inside of the package)
  • If installation fails and we have to roll back, we need to be able to re-install the baseline manifest. As a result, we'll need workload teams to have the baseline manifest properly formatted and available as well as any new updated manifests.

@sfoslund sfoslund marked this pull request as ready for review April 29, 2021 18:26
@sfoslund sfoslund requested review from joeloff, dsplaisted and wli3 April 29, 2021 18:28
@sfoslund
Copy link
Member Author

@jonathanpeppers how soon will properly named and versioned manifest packages be ready? Is it worth waiting on them to merge this PR or should we proceed with the testing I've done locally?

@dsplaisted let me know if you want me to port this to preview 4, for now I'm going to try to merge to main before there are any more conflicts.

@jonathanpeppers
Copy link
Member

@sfoslund I started on the Android side: dotnet/android#5898

It will probably be next week some time before we have the 4 Apple workloads renamed, and these changes will be in Preview 5. Assuming this PR wouldn't break anything, you don't have to wait on us for this.

@sfoslund sfoslund enabled auto-merge April 30, 2021 20:43
@sfoslund sfoslund merged commit cb5b3ff into dotnet:main Apr 30, 2021
@sfoslund sfoslund deleted the WorkloadManifestUpdates branch April 30, 2021 21:23
@sfoslund sfoslund mentioned this pull request May 3, 2021
15 tasks
Copy link
Member

@dsplaisted dsplaisted left a comment

Choose a reason for hiding this comment

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

@sfoslund This is already merged but I went back and took another look at it since I hadn't had a chance to do so before. There's a few (non-critical) things I think would be nice to follow up on and fix.

},
rollback: () => {
try
{
_reporter.WriteLine(LocalizableStrings.RollingBackInstall);

foreach (var manifest in manifestsToUpdate)
Copy link
Member

Choose a reason for hiding this comment

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

Nit: this indentation seems messed up.

Copy link
Member Author

Choose a reason for hiding this comment

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


public async Task UpdateAdvertisingManifestsAsync(SdkFeatureBand featureBand, bool includePreviews)
{
var manifests = GetInstalledManifestIds();
Copy link
Member

Choose a reason for hiding this comment

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

I still think there's a mismatch here. The IWorkloadManifestProvider is passed into the constructor, and is tied to a specific feature band. But there are instance methods on this class that also take a feature band. I think things won't work if there's a mismatch - you'll need to create a new workload manifest provider for the new feature band and then create a new workload manifest updater.

So I think we should remove the arguments from the methods in this class that take a feature band, and instead either take the feature band in the constructor, or better yet update the workload manifest provider so that it can return the feature band and we get the information from that.

}
catch (Exception e)
{
_reporter.WriteLine(string.Format(LocalizableStrings.FailedAdManifestUpdate, manifestId, e.Message));
Copy link
Member

Choose a reason for hiding this comment

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

It sounds like the failure we would expect is if there are no manifest packages available on the NuGet feed. I think we should check for that explicitly and treat it not as an error (ie when we call DownloadPackageAsync). I think other failures are probably not expected and we may want to fail.

@@ -101,6 +96,53 @@ public void GivenWorkloadInstallOnFailingRollbackItDisplaysTopLevelError()
exceptionThrown.Message.Should().Be("Failing workload: xamarin-android-build");
string.Join(" ", _reporter.Lines).Should().Contain("Rollback failure");

}

[Fact]
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Indentation

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Successfully merging this pull request may close these issues.

4 participants