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

[Feature] Smoke Test Pipeline Should Report Metrics on Application Sizes #3600

Closed
michael-hawker opened this issue Dec 4, 2020 · 7 comments
Labels
CI/pipeline 🔬 feature request 📬 A request for new changes to improve functionality help wanted Issues identified as good community contribution opportunities optimization ☄ Performance or memory usage improvements
Milestone

Comments

@michael-hawker
Copy link
Member

michael-hawker commented Dec 4, 2020

Describe the problem this feature would solve

Besides just checking the final output of the NuGet package, one reason for the Smoke Tests are to help us understand the impact the toolkit packages have on the final size of an application.

While the Smoke Tests currently run in the CI and generate these independent apps. The size isn't currently reported back in a nicely consumable way either at the end of that job or with some sort of bot back to the issue itself.

Describe the solution

MVP: When smoke test is completed, it lists a table at the end of each package and the resulting app size to the console. This way we can scroll to the end of the job and get that data when needed.

Nice to haves:

  • Compares against some well-known cache from the last build on the main branch so we can get comparison +/- with the current code base
  • Have a bot report that table back to the PR in a comment.

Additional context & Screenshots

Somewhat related to #3560 as well. And to address being able to check and help with #3145 more explicitly.

@michael-hawker michael-hawker added feature request 📬 A request for new changes to improve functionality optimization ☄ Performance or memory usage improvements CI/pipeline 🔬 labels Dec 4, 2020
@michael-hawker michael-hawker added this to the 7.0 milestone Dec 4, 2020
@michael-hawker michael-hawker added the help wanted Issues identified as good community contribution opportunities label Dec 8, 2020
@michael-hawker
Copy link
Member Author

Alright so the SmokeTests drop to SmokeTests\AppPackages and the final msixupload packages have a good breakdown of all the dependent dlls.

Each msixupload package has an inner msixbundle package and then an inner msix package, if we unzip all 3 of these, we can get a flat list of all the dlls required for the app. (Seems like there's a lot from the system, so need to check the new baseline version.) Then we can investigate what the extra dependencies are for each package besides the baseline and spit that out.

michael-hawker added a commit to michael-hawker/UWPCommunityToolkit that referenced this issue Dec 11, 2020
@michael-hawker
Copy link
Member Author

I think the strategy here I'm going to follow is to index all the files/sizes in the UWP Baseline project. Then for each other project, find the outliers to that list and report what those are and their sizes above the baseline.

This should give us not only the overall footprint each package adds to the toolkit, but it should also help us understand other dependencies each of those packages bring and how they contribute to that total.

I'll then try and output that to the console. Luckily this is something I can easily test locally. I'm going to make it a separate PowerShell script in the SmokeTests project, and then we can just call it from the DevOps YAML file after the Smoke Tests run.

@azchohfi do you know if there's a known location where we can store a file/metadata associated the last main build in DevOps or would we have to check it in somewhere to some repo? Curious if in the future we could have the script fetch that from somewhere and compare against it to know how things are changing for a given PR?

@azchohfi
Copy link
Contributor

Not sure what the best way to do this would be. We could upload an xml or json file with these results somewhere and use that, but I don't know if we could just use the same repo for that. Not sure if we could use the ADO artifacts for that either, since there is a retention policy for builds. Maybe a release pipeline could push this to an Azure storage, and then the PRs pipelines could compare it with a known URL. I'm not sure if there is a more standard way of doing this. Lets brainstorm.

@michael-hawker
Copy link
Member Author

michael-hawker commented Dec 11, 2020

@azchohfi Hmm, was just messing with the DownloadPipelineArtifact wondering if we published it as an Artifact if we could use the specific flag to somehow grab the latest pipeline artifact from the main branch? Not sure if we can get that specific with the project guid? runVersion latestFromBranch maybe? 🤔 That looks promising. I can try it out later once I get the base script running.

Ref: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/download-pipeline-artifact?view=azure-devops

@azchohfi
Copy link
Contributor

Not sure, but it seems like it might work.

@michael-hawker
Copy link
Member Author

Looking good so far:

image

Need to test in the CI. Some dependencies I didn't quite realize were so big and rooted lower in the Toolkit like System.Text.Json is large and everywhere and it pulls in another one. Also have no idea what's pulling in the Microsoft.Bcl.AsyncInterfaces dependency...?

@michael-hawker
Copy link
Member Author

Right now it just outputs to the host, need to add more to actually spit out a file that we could compare against.

When we do that, we can also output this cleaner as a table and have an extra column for the comparison.

And we could colorize it fancier too! https://stackoverflow.com/a/49038815/8798708

michael-hawker added a commit to michael-hawker/UWPCommunityToolkit that referenced this issue Dec 12, 2020
…and package sizes

Provides a more human readible way to understand our package sizes and dependencies against a baseline blank application
See more info in CommunityToolkit#3600 for potential improvements
michael-hawker added a commit to michael-hawker/UWPCommunityToolkit that referenced this issue Dec 12, 2020
…and package sizes

Provides a more human readible way to understand our package sizes and dependencies against a baseline blank application
See more info in CommunityToolkit#3600 for potential improvements
ghost pushed a commit that referenced this issue Dec 15, 2020
## Fixes #3560
This PR does the following:
- [x] Split our tests out of the single Job into two separates Jobs, these can hopefully run in parallel? We should also get separate status checks for each job? (Will see when we run this here.)
- [x] Adds a UWP Baseline Blank App, this will be useful for #3600 to compare what the minimum app size is currently with no extra dependencies.
- [x] Split out UI Tests as a separate step from the Unit Tests
- [x] Add Application Metrics Report to Smoke Tests #3600 (could be a separate PR I suppose)

## PR Type
- Build or CI related changes

## What is the current behavior?
Everything is done in one big job.

## What is the new behavior?
We have more granularity on our pipeline

## PR Checklist

Please check if your PR fulfills the following requirements:

- [ ] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->
- [ ] Sample in sample app has been added / updated (for bug fixes / features)
    - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)
- [ ] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [ ] Contains **NO** breaking changes

<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. 
     Please note that breaking changes are likely to be rejected within minor release cycles or held until major versions. -->


## Other information
@ghost ghost locked as resolved and limited conversation to collaborators Mar 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CI/pipeline 🔬 feature request 📬 A request for new changes to improve functionality help wanted Issues identified as good community contribution opportunities optimization ☄ Performance or memory usage improvements
Projects
None yet
Development

No branches or pull requests

2 participants