[Findit] Add two more gtest command line switches.

appengine/findit/waterfall/trigger_base_swarming_task_pipeline.py

 # Copyright 2016 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 import copy
 import logging
 import time
 
 from common.http_client_appengine import HttpClientAppengine as HttpClient
 from common.pipeline_wrapper import BasePipeline
@@ skipping 22 matching lines @@
     # Make a copy of the referred request and drop or overwrite some fields.
     new_request = copy.deepcopy(ref_request)
     new_request.name = self._GetSwarmingTaskName(ref_task_id)
     new_request.parent_task_id = ''
     new_request.user = ''
 
     # To force a fresh re-run and ignore cached result of any equivalent run.
     new_request.idempotent = False
 
     # Set the gtest_filter to run the given tests only.
+    # Remove existing test filter first.
+    new_request.extra_args = [
+        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')
-    new_request.extra_args = [
-        a for a in new_request.extra_args if not a.startswith('--gtest_filter')
-    ]
-    new_request.extra_args.append('--gtest_filter=%s' % ':'.join(tests))
+
+    # 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']
     new_request.env = [
         e for e in new_request.env if e['key'] not in sharding_settings
     ]
 
     # Reset tags for searching and monitoring.
     ref_name = swarming_util.GetTagValue(ref_request.tags, 'name')
     new_request.tags = []
@@ skipping 127 matching lines @@
       swarming_task.error = error
     else:
       logging.info('A Swarming task was triggered:%s', task_id)
 
     swarming_task.put()
 
     # Call the hook function after the task is triggered.
     self._OnTaskTriggered()
 
     return task_id