176 lines
7.7 KiB
YAML
Raw Normal View History

- project:
templates:
- tripleo-undercloud-jobs
- tripleo-multinode-container-minimal
- check-requirements
- release-notes-jobs-python3
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
- openstack-python-jobs
- openstack-python36-jobs
- tripleo-standalone-scenarios-full
- openstack-python37-jobs
check:
jobs:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
- openstack-tox-pep8
- openstack-tox-lower-constraints
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
- tripleo-ci-centos-7-containers-multinode:
dependencies: &deps_unit_lint
- openstack-tox-pep8
- tripleo-ci-centos-7-scenario000-multinode-oooq-container-upgrades:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-scenario000-multinode-oooq-container-updates:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
dependencies: *deps_unit_lint
files:
- ci/environments/scenario000-multinode-containers.yaml
- ^ci/common/.*$
- ^deployed-server/.*$
- ^deployment/container-image-prepare/.*$
- ^(deployment|docker|puppet)/.*ca-certs.*$
- ^(deployment|docker|puppet)/.*clustercheck.*$
- ^(deployment|docker|puppet)/.*docker.*$
- ^(deployment|docker|puppet)/.*haproxy.*$
- ^(deployment|docker|puppet)/.*kernel.*$
- ^(deployment|docker|puppet)/.*keystone.*$
- ^(deployment|docker|puppet)/.*memcached.*$
- ^(deployment|docker|puppet)/.*mysql.*$
- ^(deployment|docker|puppet)/.*ntp.*$
- ^(deployment|docker|puppet)/.*pacemaker.*$
- ^(deployment|docker|puppet)/.*rabbitmq.*$
- ^(deployment|docker|puppet)/.*snmp.*$
- ^(deployment|docker|puppet)/.*timezone.*$
- ^(deployment|docker|puppet)/.*tripleo-packages.*$
- ^(deployment|docker|puppet)/.*tripleo-firewall.*$
- ^(deployment|docker|puppet)/.*sshd.*$
- ^environments\/.*.yaml
- ^network/endpoints/.*$
- zuul.d/*
- tripleo-ci-centos-7-scenario006-multinode-oooq-container:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
dependencies: *deps_unit_lint
files:
- ^ci/common/.*$
- ^coe/kubernetes.*$
- ^environments/kubernetes.*$
- ^extraconfig/services/kubernetes.*$
- ci/environments/scenario006-multinode.yaml
- ci/pingtests/scenario006-multinode.yaml
- ^deployed-server/.*$
- ^common/.*$
- zuul.d/*
- tripleo-ci-centos-7-scenario007-multinode-oooq-container:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
dependencies: *deps_unit_lint
files:
- ci/environments/scenario007-multinode-containers.yaml
- ^(deployment|docker|puppet)/neutron-plugin-ml2.yaml #LP1765975
- ^(deployment|docker|puppet)/.*.*ovn.*$
- ^(deployment|docker|puppet)/.*tacker.*$
- ^ci/common/.*$
- ^environments\/.*.yaml
- ^deployed-server/.*$
- ^common/.*$
- zuul.d/*
- tripleo-ci-centos-7-scenario008-multinode-oooq-container:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
dependencies: *deps_unit_lint
files:
- ci/environments/scenario008-multinode-containers.yaml
- ^(deployment|docker|puppet)/(odl|opendaylight).*$
- ^(deployment|docker|puppet)/neutron-plugin-ml2.yaml #LP1765975
- ^ci/common/.*$
- ^environments\/.*.yaml
- ^deployed-server/.*$
- ^common/.*$
- zuul.d/*
- tripleo-ci-centos-7-scenario009-multinode-oooq-container:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
dependencies: *deps_unit_lint
voting: true
files:
- ^coe/openshift.*$
- ^environments/openshift.*$
- ^extraconfig/services/openshift.*$
- ^(deployment|docker|puppet)/.*haproxy.*$
- ^(deployment|docker|puppet)/.*keepalived.*$
- ^(deployment|docker|puppet)/.*mistral.*$
- ci/environments/scenario009-multinode.yaml
- ^ci/common/.*$
- ci/pingtests/scenario009-multinode.yaml
- ^network/endpoints/.*$
- ^deployed-server/.*$
- ^common/.*$
- zuul.d/*
- tripleo-ci-centos-7-scenario010-multinode-oooq-container:
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
dependencies: *deps_unit_lint
files:
- ^(deployment|docker|puppet)/.*octavia.*$
- ^deployment/ceph-ansible.*$
- ^deployment/octavia/*$
- ci/environments/scenario010-multinode-containers.yaml
- ^ci/common/.*$
- ^environments\/.*.yaml
- ^deployed-server/.*$
- ^network/endpoints/.*$
- ^common/.*$
- zuul.d/*
Delay check CI jobs until the pep8 passes.. ..for Greater Good. 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. Save CI resources and shorten wait-in-zuul-queue times for other patches, when pep8 checks failed (that is YAML validation for this t-h-t repo). 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 integration FAILURE patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 SUCCESS integration SUCCESS Future: patchset one: pep8 FAILURE integration SKIPPED patchset two: pep8 SUCCESS integration FAILURE patchset three: pep8 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: I2216773113f8d4e4a2bdff35709ff739f5164a32 Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
2019-02-26 15:54:22 +01:00
- tripleo-ci-centos-7-standalone-upgrade:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-scenario001-standalone:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-scenario002-standalone:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-scenario003-standalone:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-scenario004-standalone:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-scenario012-standalone:
dependencies: *deps_unit_lint
- tripleo-ci-centos-7-containerized-undercloud-upgrades:
dependencies: *deps_unit_lint
gate:
queue: tripleo
jobs:
- openstack-tox-lower-constraints
- openstack-tox-pep8
- tripleo-ci-centos-7-scenario000-multinode-oooq-container-updates:
files:
- ci/environments/scenario000-multinode-containers.yaml
- ^ci/common/.*$
- ^deployed-server/.*$
- ^deployment/container-image-prepare/.*$
- ^(deployment|docker|puppet)/.*ca-certs.*$
- ^(deployment|docker|puppet)/.*clustercheck.*$
- ^(deployment|docker|puppet)/.*docker.*$
- ^(deployment|docker|puppet)/.*haproxy.*$
- ^(deployment|docker|puppet)/.*kernel.*$
- ^(deployment|docker|puppet)/.*keystone.*$
- ^(deployment|docker|puppet)/.*memcached.*$
- ^(deployment|docker|puppet)/.*mysql.*$
- ^(deployment|docker|puppet)/.*ntp.*$
- ^(deployment|docker|puppet)/.*pacemaker.*$
- ^(deployment|docker|puppet)/.*rabbitmq.*$
- ^(deployment|docker|puppet)/.*snmp.*$
- ^(deployment|docker|puppet)/.*timezone.*$
- ^(deployment|docker|puppet)/.*tripleo-packages.*$
- ^(deployment|docker|puppet)/.*tripleo-firewall.*$
- ^(deployment|docker|puppet)/.*sshd.*$
- ^environments\/.*.yaml
- ^network/endpoints/.*$
- zuul.d/*
- tripleo-ci-centos-7-scenario009-multinode-oooq-container:
files:
- ^coe/openshift.*$
- ^environments/openshift.*$
- ^extraconfig/services/openshift.*$
- ^(deployment|docker|puppet)/.*haproxy.*$
- ^(deployment|docker|puppet)/.*keepalived.*$
- ^(deployment|docker|puppet)/.*mistral.*$
- ci/environments/scenario009-multinode.yaml
- ci/pingtests/scenario009-multinode.yaml
- ^network/endpoints/.*$
- ^deployed-server/.*$
- ^common/.*$
- zuul.d/*
experimental:
jobs:
- tripleo-ci-centos-7-scenario011-multinode-oooq-container:
files:
- ci/environments/scenario011-multinode-containers.yaml
- ^(deployment|docker|puppet)/.*ironic.*$
- ^environments\/.*ironic.*$