-
Notifications
You must be signed in to change notification settings - Fork 727
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
Add a new checker to check cross-feature dependency. #15559
base: master
Are you sure you want to change the base?
Add a new checker to check cross-feature dependency. #15559
Conversation
d0f622e
to
752d893
Compare
continueOnError: true | ||
pool: sonic-common | ||
steps: | ||
- script: | |
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.
suggest to use a template yml here to make azure-pipelines.yml clean
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.
There is only one step here, so I think there is no necessary to create another template file here?
os.path.join(project_path, "conftest.py"), | ||
file_feature_path]: | ||
print("There is a cross-feature dependence. File: {}, import module: {}" | ||
.format(file_path, imported_module["module"])) |
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.
Here may have duplicate prints, how about just print 1 line and continue, or you can also print the alias
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 think one script one line is more clearly for user to read.
2b725a9
to
8d6807f
Compare
Description of PR
We introduced a new approach to PR testing called
Impacted area based PR testing
. In this model, the scope of PR testing is determined by the specific areas of the code that are impacted by the changes, allowing for more focused and efficient testing.This means, we need to establish clear boundaries between different sections of code and minimize dependencies as much as possible.
In the tests directory of the
sonic-mgmt
repository, we have categorized scripts into two main groups: shared scripts and feature-specific scripts. Shared scripts provide common utilities or functionality used across multiple features, while feature-specific scripts are tied to particular features and their corresponding logic.However, the previous codebase contained a significant number of cross-feature dependencies, where scripts from one feature directly referenced or relied on scripts from another. To address this issue and align with our new testing model, we manually reviewed the existing code and removed all cross-feature references. But we need a mechanism to check future modifications and new code to prevent reintroducing these issues.
In this PR, we introduce a new checker to identify any cross-feature dependencies. At this stage, since some cross-feature dependencies remain in the code, this checker is configured to flag these dependencies without causing the entire test to fail. Once all current dependencies are fully removed, any reintroduced cross-feature dependencies detected by this checker will result in a test failure.
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
We introduced a new approach to PR testing called
Impacted area based PR testing
. In this model, the scope of PR testing is determined by the specific areas of the code that are impacted by the changes, allowing for more focused and efficient testing.This means, we need to establish clear boundaries between different sections of code and minimize dependencies as much as possible.
In the tests directory of the
sonic-mgmt
repository, we have categorized scripts into two main groups: shared scripts and feature-specific scripts. Shared scripts provide common utilities or functionality used across multiple features, while feature-specific scripts are tied to particular features and their corresponding logic.However, the previous codebase contained a significant number of cross-feature dependencies, where scripts from one feature directly referenced or relied on scripts from another. To address this issue and align with our new testing model, we manually reviewed the existing code and removed all cross-feature references. But we need a mechanism to check future modifications and new code to prevent reintroducing these issues.
In this PR, we introduce a new checker to identify any cross-feature dependencies. At this stage, since some cross-feature dependencies remain in the code, this checker is configured to flag these dependencies without causing the entire test to fail. Once all current dependencies are fully removed, any reintroduced cross-feature dependencies detected by this checker will result in a test failure.
How did you do it?
In this PR, we introduce a new checker to identify any cross-feature dependencies. At this stage, since some cross-feature dependencies remain in the code, this checker is configured to flag these dependencies without causing the entire test to fail. Once all current dependencies are fully removed, any reintroduced cross-feature dependencies detected by this checker will result in a test failure.
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation