-
Notifications
You must be signed in to change notification settings - Fork 954
Arm backend: Add manifest validation and add Backwards compabillety testing #18813
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
Open
Sebastian-Larsson
wants to merge
3
commits into
pytorch:main
Choose a base branch
from
Sebastian-Larsson:validate_manifest
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,105 @@ | ||
| # Manifests | ||
|
|
||
| Manifests are used to track the current public API of the Arm backend. They are | ||
| generated with | ||
| `python backends/arm/scripts/public_api_manifest/generate_public_api_manifest.py`. | ||
|
|
||
| ## Running manifest | ||
|
|
||
| There is always one running manifest which has the main purpose of tracking the | ||
| API surface inbetween releases. | ||
|
|
||
| ## Static manifests | ||
|
|
||
| At any given time there may be up to two static manifests. These are generated | ||
| in conjunction with a release and are used to track the API surface of that | ||
| release. The main purpose of these is to make sure backwards compatibility. | ||
|
|
||
| A static manifest may never be changed. It belongs to a release and must be kept | ||
| as is. | ||
|
|
||
| A static manifest should not live longer than 2 releases. It may then be | ||
| removed. | ||
|
|
||
| # On release | ||
|
|
||
| With each release, check that the running manifest is up to date and reflects | ||
| the API surface of the release. Then, copy the running manifest to a new static | ||
| manifest for the release. This can be done by running | ||
| `cp <running_manifest> <static_manifest>`. The new static manifest should be | ||
| named according to the release, e.g. `api_manifest_1_3.toml` for release 1.3 and | ||
| so on. If there are now more than two static manifests, remove the oldest one in | ||
| the same commit. | ||
|
|
||
| # API changes | ||
|
|
||
| When introducing an API change, the running manifest must be updated to reflect | ||
| the change. This is done by running the manifest generation script, | ||
| `python backends/arm/scripts/public_api_manifest/generate_public_api_manifest.py`. | ||
| This updates the running manifest. | ||
|
|
||
| To validate the running manifest directly, run | ||
| `python backends/arm/scripts/public_api_manifest/validate_public_api_manifest.py`. | ||
|
|
||
| To validate all manifests, use `backends/arm/scripts/pre-push`. This is the | ||
| check that must pass before the change is ready to merge. | ||
|
|
||
| Manifest validation only checks the API surface and signatures. Workflow-level | ||
| backward compatibility is covered separately by the scenario runner described | ||
| below. | ||
|
|
||
| Running-manifest validation uses exact signature matching. Any intentional API | ||
| change must update `api_manifest_running.toml`. | ||
|
|
||
| Static-manifest validation uses backward-compatibility matching. The old | ||
| release signature must still be callable against the current API. For example, | ||
| adding a trailing optional parameter is accepted for static manifests, while | ||
| removing a parameter, reordering parameters, or adding a new required | ||
| parameter still fails validation. | ||
|
|
||
| ## Backward-compatibility scenarios | ||
|
|
||
| Workflow-level backward compatibility is checked by | ||
| `python backends/arm/test/public_api_bc/run_public_api_bc_scenarios.py`. | ||
|
|
||
| The runner hardcodes the current canonical public API workflow scripts: | ||
|
|
||
| - `backends/arm/test/public_api_bc/ethosu_flow.py` | ||
| - `backends/arm/test/public_api_bc/vgf_fp_flow.py` | ||
| - `backends/arm/test/public_api_bc/vgf_int_flow.py` | ||
|
|
||
| These scripts should be updated continuously to reflect the current public API. | ||
| The runner materializes those same paths into a temporary harness and executes | ||
| them there with pytest so they import the latest installed | ||
| `executorch.backends.arm` package instead of the repository source tree. | ||
|
|
||
| The rolling support window is controlled by the `OLDEST_SUPPORTED_REF` constant | ||
| in `backends/arm/test/public_api_bc/run_public_api_bc_scenarios.py`: | ||
|
|
||
| - If `OLDEST_SUPPORTED_REF` is empty, the runner uses the current workspace. | ||
| This is the bootstrap mode until a release contains the scenario scripts. | ||
| - Once a release contains the scripts, the release epic should update | ||
| `OLDEST_SUPPORTED_REF` to the oldest still-supported release ref. | ||
| - At that point the runner uses `git show <ref>:<path>` to fetch the old | ||
| release's scripts and run them against the latest code. | ||
|
|
||
| When an old release falls out of the support window, update | ||
| `OLDEST_SUPPORTED_REF` to the next newer supported release. That is how the | ||
| backward-compatibility window rolls forward. | ||
| Reasons for passing validation may include: | ||
| - Adding a new API symbol and adding it to the running manifest. | ||
| - Removing an API that was marked as deprecated and no longer exists in any | ||
| manifest. | ||
| - Deprecated symbols do not break backward compatibility with static | ||
| manifests. | ||
| - Deprecating a symbol removes it from the running manifest, but it can only be | ||
| removed fully once it no longer appears in any static manifest. | ||
| - Extending a static-manifest signature in a backward-compatible way, such as | ||
| adding a trailing optional parameter. | ||
|
|
||
| Reasons for failing validation may include: | ||
| - Removing an API symbol without deprecation. | ||
| - Changing a running-manifest signature without regenerating the running | ||
| manifest. | ||
| - Changing a static-manifest signature in a non-backward-compatible way. | ||
| - New API symbol added but not added to the running manifest. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| # Copyright 2026 Arm Limited and/or its affiliates. | ||
| # | ||
| # This source code is licensed under the BSD-style license found in the | ||
| # LICENSE file in the root directory of this source tree. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
36 changes: 36 additions & 0 deletions
36
backends/arm/scripts/public_api_manifest/validate_all_public_api_manifests.sh
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| #!/usr/bin/env bash | ||
| # Copyright 2026 Arm Limited and/or its affiliates. | ||
| # | ||
| # This source code is licensed under the BSD-style license found in the | ||
| # LICENSE file in the root directory of this source tree. | ||
|
|
||
| set -u | ||
|
|
||
| echo "Validating Arm public API manifests" | ||
|
|
||
| manifest_failures=0 | ||
| for manifest_path in backends/arm/public_api_manifests/api_manifest_*.toml; do | ||
| if [[ ! -f "${manifest_path}" ]]; then | ||
| continue | ||
| fi | ||
| manifest_name="${manifest_path##*/}" | ||
| echo | ||
| echo "=== ${manifest_name} ===" | ||
| validator_output=$( | ||
| python backends/arm/scripts/public_api_manifest/validate_public_api_manifest.py \ | ||
| --manifest "${manifest_path}" 2>&1 | ||
| ) | ||
| validator_status=$? | ||
| printf '%s\n' "${validator_output}" | ||
| if [[ ${validator_status} -ne 0 ]]; then | ||
| manifest_failures=$((manifest_failures + 1)) | ||
| fi | ||
| done | ||
|
|
||
| echo | ||
| if [[ ${manifest_failures} -eq 0 ]]; then | ||
| echo "Arm public API manifests OK" | ||
| else | ||
| echo "${manifest_failures} manifest(s) failed validation" | ||
| exit 1 | ||
| fi |
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is not the PR introducing this API checker, but two questions,
(1) why not rely on unit-tests to enforce the actual behavior, beyond API BC
(2) why not use
Griffeor something similar to do this for you?