-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
ci: testplan generation cleanup and scope overhaul #65257
base: main
Are you sure you want to change the base?
Conversation
6d40dca
to
8883123
Compare
a15fe5d
to
f50935c
Compare
Nice, MAINTAINER file approach seems like a great plan. Do we really need the tags? Maybe the plan could just scan for sample/test yaml files under the area and add those to the plan regardless on the tag. Was also thinking, maybe it would make sense to distinguish between platform changes and subystem changes and behave differently? |
not tags right now, it is using test identifiers. There are other usecases I have in mind which will merge this data with test reports generated by twister to generate something that is feature based (feature = area). I do not want to depend on just the file globs for this, which is not reliable.
That is what the script does, no? |
scripts/get_maintainer.py
Outdated
", ".join(area.tests), | ||
", ".join(area.tags), |
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'm a bit confused by the tags here, is this a transient? You are adding handling, then adding some tags to the maintainer file, then removing the tag and only using tests or am I missing something?
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.
yes, started with tags but realized those are very random and inconsistent and do not provide direct relation and decided to look into test identifiers instead which are more accurate.
Ok fair enough, sorry not familiar with the original code, need to put more time into understanding this, see my question above about tags+tests in the maintainer file. |
f50935c
to
ac2b34f
Compare
ac2b34f
to
bac5fc0
Compare
scripts/get_maintainer.py
Outdated
@@ -479,7 +485,7 @@ def ferr(msg): | |||
|
|||
ok_keys = {"status", "maintainers", "collaborators", "inform", "files", | |||
"files-exclude", "files-regex", "files-regex-exclude", | |||
"labels", "description"} | |||
"labels", "description", "tests", "tags"} |
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.
tags in this file can be removed right?
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.
can, but leaving it does not hurt, I might have a usecase for this to improve coverage as we move forward.
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.
ack
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.
Having a hard time fining anything to comment about on the code and the history could be cleaned a bit :-), I think the whole file could use some restructuring, but so it did before, I think this is functionally a great improvement worth giving it a shot as is.
@nashif Needs rebasing. |
MAINTAINERS.yml
Outdated
@@ -1051,6 +1141,8 @@ Release Notes: | |||
- doc/hardware/peripherals/flash.rst | |||
labels: | |||
- "area: Flash" | |||
tests: | |||
- drivers.flash |
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.
Does it encompass sample.drivers.flash.shell
?
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 like the idea.
02567e9
02567e9
to
71948b1
Compare
@nashif coming back to this? |
yes, working on that now actually, it is not easy :( |
Cleanup and refactoring of some functions and arguments. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This used to make sense at some point when we had minimal emulation platforms and a few platforms. Building each changed tests for > 600 platforms just does not make sense anymore and does not scale. We should focus on emulation and running the tests rather than just randomly build them over and over again, sometimes when no functional changes are being introduced. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
- Do not depend on west.yaml changes - Change tag for cmsis-dsp to match what we have in tests and the module name in west.yaml. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Use Maintainer file for determining what tests to run in CI and stop using the limited tags file. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Create a custom level with all tests identified. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This is no longer used or needed. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
71948b1
to
ddac1db
Compare
When no commit are given, work on locally changed files. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
ddac1db
to
b3e624c
Compare
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
originally tags were introduced to reduce the number of tests we run, so, if a driver is changed, there was no need to build kernel tests and such, so it was exclusion based. This means that we would end up building loads of irrelevant tests still because tags file does only cover a few areas.
Most importantly it was abstraction based, so it was not about running tests related to what has changed, instead just reduce the number of tests not guaranteeing coverage at all of what the PR is changing.
This new approach is based on the Maintainer file and connecting areas in that file with tests, if a PR changes one area, tests for this specific area is run. There are a few other steps taken to increase coverage and to deal with special cases.
change some code in some subsys or 2, then...
./scripts/ci/test_plan.py -c HEAD~1.. or whatever
for example, changed bindesc subsystem: