Add tracking of AOT size and a pipeline to summarize it - #54682
Conversation
baronfel
added
the
Area-dotnet AOT
There was a problem hiding this comment.
Pull request overview
This PR adds end-to-end NativeAOT size tracking by generating size diagnostics during the dotnet-aot build, publishing them from Azure DevOps runs, and introducing a GitHub Actions workflow that can diff PR vs. baseline artifacts and post a summarized size-impact comment back to the PR.
Changes:
- Enable generation of NativeAOT size diagnostics artifacts (
.mstatand.dgml) fordotnet-aot. - Copy and publish those artifacts as pipeline artifacts from the SDK build job.
- Add a GitHub Actions workflow that can be triggered via
/aot-size(orworkflow_dispatch) to download PR/baseline artifacts, runsizoscope-cli, and post/update a PR comment.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/Cli/dotnet-aot/dotnet-aot.csproj | Enables emission of .mstat and .dgml size-analysis outputs during NativeAOT compilation. |
| eng/pipelines/templates/jobs/sdk-build.yml | Copies/publishes the generated size-analysis files as a pipeline artifact for downstream consumption. |
| .github/workflows/aot-size-analysis.yml | Adds a slash-command/dispatch workflow to download artifacts from AzDO, diff them via sizoscope-cli, and comment results on the PR. |
Use createForPullRequestReviewComment when the trigger is a pull_request_review_comment, since createForIssueComment targets a different API resource and would fail for review comments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
47bd03e to
67b9a6a
Compare
There was a problem hiding this comment.
I love this idea, we should be smarter about these size differences. Thank you and sorry you waited a while for review.
One question I have about the broad approach is that I thought azdo or other tools had (relatively https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/perf-test/rsat/rsat-run) built-in integration for size or other regression tracking with a chart over time? I want to make sure we aren't re-inventing the wheel. I believe C# devkit is doing that, and if we could do that when we do the build itself (flagged depending upon a property or perhaps changes to the /aot/ folder) rather than here, that would save resources.
Edit: (I'm not going to block this by being nitpicky about the approach though, this is still of course net good)
The analyze job runs sizoscope-cli with only contents:read permission, then uploads the report as a workflow artifact. A separate comment job downloads the artifact and posts to the PR with write permissions. This ensures the analysis code (which processes external build artifacts) never has write access to the repository. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
67b9a6a to
7972e5a
Compare
Server-side filtering by refs/pull/{N}/merge is more reliable than
fetching top-20 builds and filtering client-side by SHA, which could
miss the build if many other builds ran since.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Explicitly blank GITHUB_TOKEN, GH_TOKEN, and Actions runtime tokens in the analyze job so that sizoscope-cli and other tooling cannot access or exfiltrate credentials. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Now that we're making an AOT artifact, we should be aware of the size impact of dependencies/optimizations/etc.
This PR helps us establish this awareness by
The GHA workflow is triggered manually or via
/aot-sizecomments on a PR. I've also run zizmor on it already.