opendev/elastic-recheck
Code Issues Proposed changes

Elaborate on the limitations of test_id filtering

Browse Source 
This commit attempts to clearly state the current limitations with
using test_id filtering. Previously it wasn't entirely clear to some
people when you could use the test_id filtering because of the current
limitations in the subunit2sql data.

Change-Id: I580b45651283b0ffc851cc4369e883155fd5c5fd
This commit is contained in:
Matthew Treinish 2015-08-28 16:38:11 -04:00
parent a956275f66
commit 830dad45d5
1 changed files with 5 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
README.rst
View File

@ -75,8 +75,9 @@ example, 'smoke', 'slow', any service tags, etc. This is how subunit-trace
prints the test ids by default if you're using it. If any of the listed
test_ids match as failing for the run being checked with the query it will
return a match. Since filtering leverages subunit2sql which only receives
results from the gate pipeline, this technique will only work on the gate
queue. For example, if your query yaml file looked like::
tempest test results from the gate pipeline, this technique will only work on
tempest or grenade jobs in the gate queue. For more information about this
refer to the `infra subunit2sql documentation`_ For example, if your query yaml file looked like::
query: >-
message:"ExceptionA"
@ -88,6 +89,8 @@ this will only match the bug if the logstash query had a hit for the run and
either test_update_server_name or test_server_set_empty name failed during the
run.
.. _infra subunit2sql documentation: http://docs.openstack.org/infra/system-config/logstash.html#subunit2sql
In order to support rapidly added queries, it's considered socially acceptable
to approve changes that only add 1 new bug query, and to even self approve
those changes by core reviewers.