Delay check CI jobs until the pep8/unit passes..
Delay check CI jobs until the pep8/unit passes..

..for Greater Good.
Save CI resources and shorten wait-in-zuul-queue times
for other patches, when tox/pep8 checks failed.

NOTE: for example, standalone jobs are defined as a template in
tripleo-ci, and here we are adding and override the listed jobs for the
dependencies/files options. If a job is added to the standlone template
in tripleo-ci, we need to add the job and dependency here manually.
If we won't, that job will be consumed as is and run w/o dependencies.
That is the price to pay for not having overrides managed centrally in
tripleo-ci. The latter wouldn't work neither as a single template
cannot fit all the specific needs of numerous tripleo repos. So the
final call was made to manage overrides via local overrides for tripleo
repos.

For core openstack python projects it might make sense to
not split them apart and run them all together. For things like
TripleO/Kolla/Puppet/etc where we have layers of interactions that can
be affected by the results from the linters/unit jobs it makes
sense to split them out.

For example, in tripleo since we use packages, if the unit test fails
the integration test may fail because when we go to built the package
with the new source, the unit test int he package build fails.  Thus
we know that'll be a wasted execution and you won't actually get any
results.

An alternative Today:
  patchset one:
    pep8 SUCCESS
    unittest FAILURE
    integration FAILURE
  patchset two:
    pep8 SUCCESS
    unittest SUCCESS
    integration FAILURE
  patchset three:
    pep8 SUCCESS
    unittest SUCCESS
    integration SUCCESS

Future:
  patchset one:
    pep8 SUCCESS
    unittest FAILURE
    integration SKIPPED
  patchset two:
    pep8 SUCCESS
    unittest SUCCESS
    integration FAILURE
  patchset three:
    pep8 SUCCESS
    unittest SUCCESS
    integration SUCCESS

This may not be true for devstack but if the unit
tests are failing, then the code is likely bad (backwards
compatibility/wrong assumptions about change/etc) and we shouldn't be
running an actual deployment.

Related upstream ML threads:
* http://lists.openstack.org/pipermail/openstack-dev/2018-March/
127869.html
* http://lists.openstack.org/pipermail/openstack-discuss/
2019-February/003142.html

Change-Id: I0799a50adbc253100fa69a54277c447680d2b3e2
Signed-off-by: Bogdan Dobrelya <a2228ae37d00d1cbd5a93e53f3e1e5aef21d5900@redhat.com>

openstack/tripleo-common,openstack/tripleo-common