[Findit] Add two more gtest command line switches.

appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py

Index: appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py
diff --git a/appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py b/appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py
index f3401a2a41047b70e186efd095f2d7fdaf82f59a..d336140bd3988ec09f94ebb9c2130e9a54810212 100644
--- a/appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py
+++ b/appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py
@@ -40,12 +40,24 @@ class TriggerBaseSwarmingTaskPipeline(BasePipeline):  # pragma: no cover.
     new_request.idempotent = False
 
     # Set the gtest_filter to run the given tests only.
-    new_request.extra_args.append('--gtest_repeat=%s' % iterations)
-    new_request.extra_args.append('--test-launcher-retry-limit=0')
+    # Remove existing test filter first.
     new_request.extra_args = [
-        a for a in new_request.extra_args if not a.startswith('--gtest_filter')
+        a for a in new_request.extra_args if (
+            not a.startswith('--gtest_filter') and

[lijeffrey, 2016/11/29 05:51:30]

So I'm not actually familiar with these flags, where are they documented/defined
for further reading?

[stgao, 2016/11/29 07:38:53]

For gtest_filter, you may search on gtest documentation.
For test-launcher-filter-file, you may search it in the chromium codebase.

You may want to learn related switches/settings when you have a chance.

+            not a.startswith('--test-launcher-filter-file'))
     ]
     new_request.extra_args.append('--gtest_filter=%s' % ':'.join(tests))
+    new_request.extra_args.append('--gtest_repeat=%s' % iterations)
+    new_request.extra_args.append('--test-launcher-retry-limit=0')
+
+    # Also rerun disabled tests. Scenario:
+    #   1. A gtest becomes flaky.
+    #   2. It is disabled, but no culprit is identified.
+    #   3. Some dev starts investigation and requests Findit to analyze.
+    #   4. From the starting build, the test is already disabled.
+    # This scenario could happen if the flaky test didn't trigger an analysis
+    # before it is disabled.
+    new_request.extra_args.append('--gtest_also_run_disabled_tests')

[chanli, 2016/11/29 05:04:48]

Question: for more general cases, shouldn't we stop the swarming task when we
found the test has been disabled?

[stgao, 2016/11/29 07:38:53]

Two questions before I could answer your question :)
And I updated the description a little bit to make it more clear.

1. Is it possible to distinguish the cases you referred to from the cases
described here (the test got disabled before Findit runs any analysis)?
2. Why we should stop the swarming task? Is it just a skip of rerun at the
selected build? Will the analysis continue to run or just stop?

[chanli, 2016/11/29 17:52:32]

IIUC, we don't treat disabling a flaky test as a solution to flakiness, right?
If that's correct, I don't have further questions.

[stgao, 2016/11/29 18:09:36]

No, disabling is just a temporary workaround.

 
     # Remove the env setting for sharding.
     sharding_settings = ['GTEST_SHARD_INDEX', 'GTEST_TOTAL_SHARDS']