-
Notifications
You must be signed in to change notification settings - Fork 7k
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
tests: posix + libc/thrd: one tier0 integration platform per arch, improved libc coverage #76377
tests: posix + libc/thrd: one tier0 integration platform per arch, improved libc coverage #76377
Conversation
9fbc0da
to
fa87c8a
Compare
tests: | ||
portability.posix.eventfd: {} |
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.
Given that picolibc is usually the default, it looks like this configuration will test against picolibc twice and never test against minimal libc?
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.
It's been a while, but IIRC the reason why the base case exists and is empty is to allow people to override things easier on the command line. So, for example, if a completely external libc was used, people could still run the suite without having to n-select anything in addition to y-selecting things.
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 could add an explicit case for the minimal libc though. Good catch 👍
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.
Thanks, that makes good sense, it's nice to provide a way for people to test things outside of the "known" C libraries. I was mostly wondering if we want to test minimal libc at all, because aiui, it's not happening with the proposed change (I don't know about the pre-patch status).
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.
Went through all of them and made sure there was a .minimal
case as well. So far so good on my desk, so I'll push.
INFO - Added initial list of jobs to queue
INFO - Total complete: 1822/2488 73% skipped: 1341, failed: 0, error: 0
If it makes sense to reduce coverage in certain areas, please make suggestions. There is unfortunately a bit of a compromise to make between fast CI and sufficient coverage to ensure things are regression-free, while simultaneously testing most / all architectures and most / all libc's. |
fa87c8a
to
dd4e5fc
Compare
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.
Definitely make sense to me to increase the test coverage of these building blocks
Add one tier0 platform per supported architecture. Signed-off-by: Chris Friedt <[email protected]>
dd4e5fc
to
a34026d
Compare
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.
Refresh +1
@keith-packard - feel up for a re-review? @nashif - PTAL. Your change request was made. |
re-ping @nashif |
The intent of this change is to mitigate the possibility of regressions in POSIX and related areas due to lack of test coverage between multiple architectures and multiple C libraries. There is unfortunately a compromise to make between fast CI and sufficient test coverage.
If it makes sense to reduce the scope in certain areas, please feel free to make suggestions.
Add one tier0 integration platform per supported architecture, and increase libc coverage.
Note
Depending on other suite constraints, only certain tier0 platforms may be used for certain suites (e.g.
netif
dependency)