On Thu, Sep 21, 2017 at 03:49:38PM +0100, Mark Brown wrote:
On Wed, Sep 20, 2017 at 07:15:40PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 06:00:57PM +0100, Mark Brown wrote:
But... more testing is better right? :) It's pretty much what all the other automatic stuff does, so long as the testing load doesn't overwhelm the systems it's going to be the easiest way to help people find things if they go trawling for historic information and I guess also provides a bit of security against mistakes.
When it is the same exact git commit id, hopefully something in the test framework will "know" it has already started a test run for that same commit...
Well, I can dream...
To me the report vs the duplicate test runs are a separate thing - it's probably useful to do the report for consistency, if it happens to recycle old test results to do it that's just a useful implementation optimization (and possibly you might get a few extras if there's new or fixed infrastructure somewhere).
Though wouldn't the commit ID have changed anyway when you updated the Makefile from -rc to final?
Yes, but that commit is is identical to the commit id in the linux-stable tree, as that is where it comes from. The point being that the two trees are related, so if the same exact commit shows up in both places, no need to run the tests twice, right?
I don't know if the system can handle stuff like this though, if not, it's not a big deal, just will cut down on test system loads, and email outputs.
thanks,
greg k-h