cmake: Introduce ctest labels for testing#29844
Conversation
epuertat
left a comment
There was a problem hiding this comment.
Looks ok. Just a few suggestions/questions left over there.
|
i'd recommend s/build:/cmake:/ in the title of your commit message. we could be more specific here. |
59f9a1c to
e9e5f6f
Compare
epuertat
left a comment
There was a problem hiding this comment.
Looks like this is improving even further! Thanks @wjwithagen! Just a few suggestions: mostly related to the hardcoded values and perhaps explaining this in Ceph Developer's docs.
|
BTW, with the help of @alfredodeza we've created a Jenkins Build Analyzer parser for CTest Failures, so the output in case of failure (like the above "make check fail") would look like the following:
|
|
You can supress the total label runtime if wanted with |
bb5b582 to
46e677f
Compare
epuertat
left a comment
There was a problem hiding this comment.
Looks great. Just added a minor suggestion to improve the docs already provided. Thanks a lot for this @wjwithagen !
46e677f to
f125dcc
Compare
a854a58 to
169d9f6
Compare
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
Keep away from this, bad stale bot! I think this is valuable in order to speed-up/fine-tune CI. |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
| Labels can be selected with ctest -L or -LE | ||
|
|
||
| Since COST is used to determine the testing order, values can be chosen rather | ||
| arbitrarily. Currently long running programs are given a value equal to the |
There was a problem hiding this comment.
Zac may have a different view, but I'd make it long-running.
| execution time in a OpenStack VM. The idea is to first run the long standing | ||
| tests, and then fill up free cores with programs with shorter execution time. | ||
| Turning this into a bin-packing challenge, So the exact value is not important, | ||
| it is about the relative COST value. |
There was a problem hiding this comment.
an OpenStack. But conceptually I'm a bit unclear, how is OpenStack involved? Wouldn't runtime in an OpenStack instance be a function of the aggregate's overcommit policy, the instance flavor, and and the underlying CPU model? Where does the numerical COST come from? Historical data? Enquiring minds want to know.
"The idea is to first run the long-running tests, and then fill unused cores with tests with shorter execution time.
This is effectively a bin-packing challenge, so the exact values are not important, bur rather relative COST value.
There was a problem hiding this comment.
an OpenStack. But conceptually I'm a bit unclear, how is OpenStack involved? Wouldn't runtime in an OpenStack instance be a function of the aggregate's overcommit policy, the instance flavor, and and the underlying CPU model? Where does the numerical COST come from? Historical data? Enquiring minds want to know."The idea is to first run the long-running tests, and then fill unused cores with tests with shorter execution time. This is effectively a bin-packing challenge, so the exact values are not important, bur rather relative COST value.
The main purpose here is to prevent that run in a multi-core environment and try to schedule to very long running jobs at the end of test-run, since that could extend the test-run time with like 5 - 10 minutes.
'Openstack ' refers to the fact that I was running these builds in an OpenStack system. But like I indicated COST is only used to steer the bin-packing algorithm, no use in getting exact numbers, order of magnitude will already work.
And I used the times that I found in my runs.
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution! |
|
@wjwithagen - i am unsure if you are still working on ceph BUT was hoping/wondering if we can/should revive this PR. We are trying to improve the general builds, tests - developer experience around this and I think would really help with that endeavor |
|
Recovering this PR in the context of CI improvements, as this would enable both:
|
@cbodley is trying out an approach to do this based on parsing |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution! |
cmake: Introduce ctest TEST labels for testing and COST
Tests in CMake/Ctest can have labels on which can be filtered
Which allows to run certain subsets of by using RE filters
in ctest.
COST will determine the order in which the tests are executed.
Current settings will start with long running tests.
Like:
Checklist
Show available Jenkins commands
jenkins retest this pleasejenkins test make checkjenkins test make check arm64jenkins test submodulesjenkins test dashboardjenkins test dashboard backendjenkins test docsjenkins render docs