Refactor sanity check to use dynamic check fixtures#2883
Merged
wangxin merged 2 commits intosonic-net:masterfrom Jan 29, 2021
wangxin:refactor-sanity
Merged
Refactor sanity check to use dynamic check fixtures#2883wangxin merged 2 commits intosonic-net:masterfrom wangxin:refactor-sanity
wangxin merged 2 commits intosonic-net:masterfrom
wangxin:refactor-sanity
Conversation
The check items are defined in the `checks.py` module. In the original design, check item is defined as an ordinary function. All the dependent fixtures must be specified in the argument list of `sanity_check`. Then objects of the fixtures are passed to the check functions as arguments. However, this design has a limitation. Not all the sanity check dependent fixtures are supported on all topologies. On some topologies, sanity check may fail with getting those fixtures. To resolve that issue, this PR changed the design. Now the check items must be defined as fixtures. Then the check fixtures can be dynamically attached to test cases during run time. In the sanity check plugin, we can check the current testbed type or other conditions to decide whether or not to load certain check fixtures. Signed-off-by: Xin Wang <xiwang5@microsoft.com>
|
This pull request introduces 1 alert when merging 922dd63 into 93f655a - view on LGTM.com new alerts:
|
yxieca
approved these changes
Jan 28, 2021
Contributor
|
/Azurepipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
theasianpianist
approved these changes
Jan 28, 2021
kazinator-arista
pushed a commit
to kazinator-arista/sonic-mgmt
that referenced
this pull request
Mar 4, 2026
…atically (sonic-net#15590) src/sonic-utilities * 436ecb06 - (HEAD -> 202205, origin/202205) [GCU Feature Update] Cherry-pick Platform Validator PR to 202205 (sonic-net#2883) (4 days ago) [isabelmsft] * 17874100 - [202205][db_migrator] Add migration of FLEX_COUNTER_DELAY_STATUS during 1911->2211 upgrade + fast-reboot. Add UT. (sonic-net#2870) (5 days ago) [Vadym Hlushko]
kazinator-arista
pushed a commit
to kazinator-arista/sonic-mgmt
that referenced
this pull request
Mar 4, 2026
…atically (sonic-net#15809) src/sonic-utilities * 20853a6f - (HEAD -> 202205, origin/202205) Revert "[GCU Feature Update] Cherry-pick Platform Validator PR to 202205 (sonic-net#2883)" (sonic-net#2908) (6 hours ago) [isabelmsft]
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Description of PR
Summary:
Fixes # (issue)
Type of change
Approach
What is the motivation for this PR?
The check items are defined in the
checks.pymodule. In the original design, check item is defined as an ordinary function. All the dependent fixtures must be specified in the argument list ofsanity_check. Then objects of the fixtures are passed to the check functions as arguments. However, this design has a limitation. Not all the sanity check dependent fixtures are supported on all topologies. On some topologies, sanity check may fail with getting those fixtures.How did you do it?
To resolve that issue, this PR changed the design. Now the check items must be defined as fixtures. Then the check fixtures can be dynamically attached to test cases during run time. In the sanity check plugin, we can check the current testbed type or other conditions to decide whether or not to load certain check fixtures.
How did you verify/test it?
Use a customized test script to verify the combinations of sanity check supported marks and command line options.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation