http://bugs.winehq.org/show_bug.cgi?id=31789
Bug #: 31789 Summary: Fix handling of jscript/vbscript tests Product: Wine-Testbot Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: unknown AssignedTo: wine-bugs@winehq.org ReportedBy: fgouget@codeweavers.com Classification: Unclassified
The Wine TestBot reports failures for all patches to the jscript/vbscript tests:
=== W7PROX64 (32 bit) === No test summary line found
This generates quite a bit of spam on wine-devel and is annoying and needs to be fixed. I believe it also happens with some other tests.
http://bugs.winehq.org/show_bug.cgi?id=31789
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #1 from Jacek Caban jacek@codeweavers.com 2012-09-25 04:17:37 CDT --- Yeah, those are annoying. Wine TestBot guesses which tests to run based on modified files, but when a file change that is not test C file, it lacks informations required associate changed file with tests to run. Eg. jscript/tests/*.js changes should be handled like jscript/tests/run.c changes.
Other examples of such cases would be mshtml and wscript tests.
http://bugs.winehq.org/show_bug.cgi?id=31789
--- Comment #2 from François Gouget fgouget@codeweavers.com 2012-10-19 06:06:40 CDT --- Ideally when a patch touches a non-C file, WineTestBot should re-run all the tests for that dll/program. The problem is that for that it needs to know the list of .c files. But the job and related tasks are created by the WineTestBot server which does not have access to the Wine source.
http://bugs.winehq.org/show_bug.cgi?id=31789
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|wine-bugs@winehq.org |fgouget@codeweavers.com
--- Comment #3 from François Gouget fgouget@codeweavers.com 2012-12-17 16:32:20 CST --- One solution for that is to leverage the daily Reconfig task to build a list of all the test files and to send it to the WineTestBot server (to be stored somewhere under var). Then, when WineTestBot detects a non-C files is modified in a given test, it would add all that test's C files to the set of C files modified by that patch.
Another solution may be to leverage the fact that WineTestBot is now running on the WineHQ server if I can figure out what this actually gives us access to.
http://bugs.winehq.org/show_bug.cgi?id=31789
--- Comment #4 from François Gouget fgouget@codeweavers.com 2013-03-20 13:04:08 CDT --- There are two other (unlikely) related scenarios: * A patch that modifies the tests/Makefile and no test. * A patch that removes a test file. To the WineTestBot this is actually the same as the previous case because it sees no '+++' line impacting a test (for the deleted file we have '+++ /dev/null' which is rightfully ignored).
As a further note, we might at some point be able to access the Wine source code on the WineTestBot server. It depends how the integration with the patches website and other bits evolve.
http://bugs.winehq.org/show_bug.cgi?id=31789
Shuai Meng mengshuaicalendr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mengshuaicalendr@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=31789
--- Comment #5 from François Gouget fgouget@codeweavers.com --- Here's an impact analysis: * bin/build/Reconfig.pl Produce a list of the C files in each directory. * bin/WineRunReconfig.pl Retrieve and store the list of test C files somewhere. * lib/WineTestBot/Patches.pm Detect patches that modify non-C files in a tests directory and then consult the list of all Wine test C files we got from the Reconfig task to build a list of tests we should probably run.
Drawbacks of this hacky approach: * It's likely to cause mild test bombs: whenever this triggers the TestBot will create one task per test per VM (with the current VM list for jscript that would be 56 tasks for instance). * Any failure in any of the tests being run will be reported, thus possibly increasing the false positives rate (though obviously the fix is to make sure the tests never fail).
So a better solution would instead do a global rebuild to figure out the exact list of tests that need to be rebuilt and leverage the fix for bug 39512. But that requires even more changes.
https://bugs.winehq.org/show_bug.cgi?id=31789
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42179
https://bugs.winehq.org/show_bug.cgi?id=31789
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #6 from François Gouget fgouget@codeweavers.com --- This is fixed as described in the previous comment.
commit 049ee751f8e742f2488de2b1a2bed438d47500c9 Author: Francois Gouget fgouget@codeweavers.com Date: Thu May 18 06:58:29 2017 +0200
testbot/WineRunReconfig: Don't update the TestList if the Reconfig failed.
If we failed to update/rebuild Wine then we will stick with the old Wine and we should still use the old test list.
Signed-off-by: Francois Gouget fgouget@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
commit 83dc05b3eb3244bd6de4ce41d46834ccd73f2edf Author: Francois Gouget fgouget@codeweavers.com Date: Mon Apr 3 01:50:23 2017 +0200
testbot: Rerun all of a module's test units when a non-C file is modified.
This typically happens when a resource file is modified or a test unit is deleted.
Signed-off-by: Francois Gouget fgouget@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=31789
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Austin English austinenglish@gmail.com --- Closing.