Update git submodules

* Update paunch from branch 'master'
  - Merge "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: I967ff0323756e63e9bd66049080dde2a870399fd
    Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
This commit is contained in:
Zuul 2019-03-12 17:03:28 +00:00 committed by Gerrit Code Review
parent 8b84d746df
commit b6d9eb258d
1 changed files with 1 additions and 1 deletions

2
paunch

@ -1 +1 @@
Subproject commit a6f17e52dedfa7c229b7b8d8e1148aaa77a30916
Subproject commit 8a61464c92d5aa1450c95543ad57eb9e6b6bdc7b