High Level Design of Impacted Area based PR testing.#14761
High Level Design of Impacted Area based PR testing.#14761wangxin merged 5 commits intosonic-net:masterfrom
Conversation
| We will maintain a set of test scripts for each topology, | ||
| allowing us to select relevant scripts based on the corresponding topology set within the change scope. | ||
| This method eliminates unnecessary processes by executing only the on-demand scripts, | ||
| resulting in reduced running time. |
There was a problem hiding this comment.
Please elaborate the 2nd recommended approach.
| ### To schedule instances automatically | ||
| We will dynamically allocate instances based on the number of scripts each PR checker executes. | ||
| By analyzing the running time of each script from previous runs, | ||
| we will allocate instances proportional to the total execution time for each PR checker. |
There was a problem hiding this comment.
Please elaborate more about how to decide how many instances to use.
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
6c29fc2 to
2854b2f
Compare
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
1 similar comment
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
| including the running time, date, results, and more. | ||
| To determine the preset running time for each test script, | ||
| we will calculate the average running time of the latest five run times. | ||
| If no relevant records are found in Kusto, a default value(1800s per script) will be used for the preset running time. |
There was a problem hiding this comment.
1800s per script, 1800s is 30 minutes, how to determine this?
There was a problem hiding this comment.
This time is to keep pace with Elastictest.
| To achieve our goal, we carried out some preparatory work by eliminating these cross-feature dependencies. | ||
|
|
||
|
|
||
| ## Design |
There was a problem hiding this comment.
Could you add a chart to clarify the workflow?
There was a problem hiding this comment.
Which workflow? Here, we just manually remove the cross-feature dependencies.
There was a problem hiding this comment.
The design flowchart, step by step
There was a problem hiding this comment.
I think each step is listed as a subtitle in the part "Design". Here, we can not see the process dynamically, so I don't think it's necessary to add the flowchart.
What is the motivation for this PR? We introduce a new model of PR testing called "Impacted Area-Based PR Testing," designed to be time-efficient, cost-efficient, and highly flexible. The HLD is detailed in #14761, and this PR represents its implementation How did you do it? We redefine the scope of PR testing by impacted area, which means we will only run the test scripts really affected by the changes. How did you verify/test it? Test by pipeline.
What is the motivation for this PR? In PR #14761, we introduced the HLD for Impacted Area-Based PR testing. However, the document was placed in an outdated path. In this PR, we relocate it to the correct path. How did you do it? In this PR, we relocate the HLD to the correct path.
What is the motivation for this PR? We introduce a new model of PR testing called "Impacted Area-Based PR Testing," designed to be time-efficient, cost-efficient, and highly flexible. The HLD is detailed in sonic-net#14761, and this PR represents its implementation How did you do it? We redefine the scope of PR testing by impacted area, which means we will only run the test scripts really affected by the changes. How did you verify/test it? Test by pipeline.
We propose a model of PR testing called "Impacted Area based PR testing", which determined the scope of PR testing based on the impacted area. It reduces both time and cost efficiently. This PR is the high level design of this new model of PR testing.
What is the motivation for this PR? In PR sonic-net#14761, we introduced the HLD for Impacted Area-Based PR testing. However, the document was placed in an outdated path. In this PR, we relocate it to the correct path. How did you do it? In this PR, we relocate the HLD to the correct path.
Description of PR
We propose a model of PR testing called "Impacted Area based PR testing", which determined the scope of PR testing based on the inpacted area. It reduces both time and cost efficiently. This PR is the high level design of this new model of PR testing.
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
We propose a model of PR testing called "Impacted Area based PR testing", which determined the scope of PR testing based on the inpacted area. It reduces both time and cost efficiently. This PR is the high level design of this new model of PR testing.
How did you do it?
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation