Add component governance manifest for WebGPU EP#28599
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
Adds a WebGPU-scoped Component Governance manifest and supporting tooling/docs so WebGPU packaging pipelines can generate accurate third-party notices for Dawn/DXC and Dawn-derived dependencies without treating them as global ORT deps.
Changes:
- Added
cgmanifests/webgpu/cgmanifest.jsoncapturing Dawn, DXC, and Dawn DEPS-derived git dependencies with classification metadata. - Added documentation describing the manifest scope, dependency classification policy, and update workflow.
- Added a Python validator to detect drift between the manifest and the pinned Dawn commit (
cmake/deps.txt) and DXC release (plugin-win-webgpu-stage.yml).
Show a summary per file
| File | Description |
|---|---|
| tools/python/validate_webgpu_cgmanifest.py | Adds a drift-check script for Dawn commit + DXC release pins referenced by WebGPU builds. |
| cgmanifests/webgpu/README.md | Documents scope, classification policy, and maintenance steps for the WebGPU manifest. |
| cgmanifests/webgpu/cgmanifest.json | New WebGPU-specific dependency inventory (Dawn root + DEPS graph + DXC release metadata). |
| cgmanifests/README.md | Notes the existence/scope of the WebGPU-specific manifest. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 4/4 changed files
- Comments generated: 4
|
|
||
| 1. Update the Dawn registration to match the `dawn` entry in `cmake\deps.txt`. | ||
| 2. Re-audit the pinned upstream Dawn `DEPS` file and update Dawn-derived registrations, comments, and | ||
| `dependencyRoots`. |
There was a problem hiding this comment.
is this a manual process or is it possible to script it? if it's manual, it would be good to have more detailed instructions on how to do this.
There was a problem hiding this comment.
At the moment, this would be a manual process. I added a bit more detail, please let me know if there are any other changes you'd like to see here.
| 1. Update the Dawn registration to match the `dawn` entry in `cmake\deps.txt`. | ||
| 2. Re-audit the pinned upstream Dawn `DEPS` file and update Dawn-derived registrations, comments, and | ||
| `dependencyRoots`. | ||
| 3. If the Windows WebGPU plugin pipeline changes the downloaded DXC release, update the DirectXShaderCompiler release |
There was a problem hiding this comment.
why is the one we're downloading different from Dawn's DirectXShaderCompiler commit?
https://github.com/google/dawn/blob/ec7b457e5bb1fcec6f59733c4f3dd84d2f885a38/DEPS#L373
@guschmue do you know?
| See [here](https://docs.opensource.microsoft.com/tools/cg/cgmanifest.html) for details. | ||
|
|
||
| The WebGPU-specific manifest is in `webgpu\cgmanifest.json`. It is scoped to builds that enable the WebGPU | ||
| Execution Provider and should be selected explicitly by WebGPU packaging or NOTICE-generation pipelines. |
There was a problem hiding this comment.
is there a way to configure this scoping? IIRC, all the cgmanifest.json files were picked up by default.
There was a problem hiding this comment.
Yeah, you are right. I thought about it and what I'd propose is to name this manifest something that won't explicitly get included in normal ONNX runtime pipelines. And then any pipelines that build WebGPU and want to opt into the scanning would need to add a step to rename the file. Let me know what you think.
Description
Added a WebGPU-specific Component Governance manifest for Dawn and related dependencies.
Added documentation for the manifest scope, dependency classification, and maintenance steps. Added a validation script to catch Dawn and DXC pin drift.
Motivation and Context
WebGPU builds depend on Dawn and related components that are not part of vanilla ONNX Runtime builds.
Downstream WebGPU packaging needs ORT-owned metadata to generate complete third-party notices without maintaining a duplicate dependency inventory.