Measuring coverage for each patch will help us pinpoint
where we lack test coverage and quickly determine if
the newly introduced code doesn't have negative impact on it.
Coverage measurement is not set as a dependcy for the more complex actions
in the check pipeline, so we are unlikely to see delays in patches passing.
Signed-off-by: Jiri Podivin <jpodivin@redhat.com>
Change-Id: Ic37d30c8c1920f7d315dd7da12418d60509c42d4
At some point in the near future we'll need to move
away from Python 3.6. We should probably ensure
everything is working for newer versions of python
as well.
Change-Id: Id20ea18518080a502a4ccd9b54f6f153b2001c46
In order to test the TripleO CLI for Validations and the whole chain to avoid
blocker and regression, this patch enable Validation at the end of the Standalone job.
The cost of it, is arround 3 or 4 minutes max.
Change-Id: Ide76602bc4ccf217af00678485d8ea5c5f462bfe
This removes unnecessary zuul layout overrides. The containers
multinode and standalone/scenarios are already included via the
wired-up templates. Keeps only the undercloud-minion which is not
in the tripleo-multinode-container-minimal-pipeline [1] but updates
the consumer job vars. Part of tripleo-ci optimisation at [2].
[1] 67a58a4378/zuul.d/multinode-jobs.yaml (L71-L85)
[2] https://review.opendev.org/q/topic:tripleo-ci-reduce
Change-Id: I7c4ba85cbc1525079a94cb76aa9576b24f1d0fbb
If linting fails, content provider still builds.
Whis is suboptimal, since standalone/multinode jobs will be skipped and
nothing will use those builds.
Put cprovider into dependency on the linting jobs as well.
Change-Id: Icdd2c581c8e610eb687042044c2a8f3efee44527
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
This file, and its tests, are not useful for tripleo so we're
removing because they're now becoming problematic.
Change-Id: I656105826e5fa85ffaf077bdc831fa5800ad493c
Signed-off-by: Kevin Carter <kecarter@redhat.com>
ubi-8 based jobs uses tcib method of building containers
and same method also used by content-provider jobs.
We nearly migrated to content-provider, this jobs
are no longer in use.
Change-Id: I499a1d8f985843cf11dfb3b620e119a895380fe1
Signed-off-by: Amol Kahat <amolkahat@gmail.com>
This change switches templates and jobs to the content provider
dependency relation so the jobs share the produced artifacts.
Depends-On: https://review.opendev.org/#/c/756128
Change-Id: I710944ef28c130ae403921a73580dce9276e5060
Only run tripleo-build-containers-ubi-8 when we touch the code that
builds container images.
Depends-On: I50e0b773273910ed7e4884d52106f07003d4e080
Change-Id: I8367fb3b140f38bb61a32dedafd36052897ce80b
openstack-python3-ussuri-jobs has the py36/py37/pep8 jobs defined
and should be used for the current master since when we branch
for ussuri, this will be correct.
Change-Id: I9413dcf5d865054e8ce70be8f743cc06800e73fb
cloudnull the incredible and slayed the
py27 dragon and brought back it's head.
He also returned w/ a working py27 unit
test job that allows dlrn builds to
also work properly.
Related-Change: https://review.opendev.org/#/c/704859/
Change-Id: Ic70d9c5b5cbeca58e6640291cdb3f8840d90eca2
We believe there is a recent change in stestr that might break python27:
af0fdae10d
Until we figure it out, let's disable py27 testing which anyway will be
removed soon once we roll out centos8 testing.
- Disabling voting on openstack-tox-py27
- Remove it from the gate queue
- Stop using the openstack-python-jobs template
Change-Id: I2973ab7c6385f56ccb46f0f0cc82f32cfc56c87c
..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: I60dfb82cf4020fa64ed6952f7f0fb9f49899d91f
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Now we have a project-template to run it at projects
Depends-On: https://review.openstack.org/634231
Change-Id: Ie6328cb41b5ba7993ab329daec7c8c9bfa75b1ca
Small cleanups:
* Use openstack-lower-constraints-jobs template, remove individual
jobs.
* Sort list of templates
Change-Id: I4c107cd94d4e712d2a14eb2b2b68dbe12701322d
Needed-By: https://review.openstack.org/623229
https://review.openstack.org/#/c/619337/ switched the jobs to a noop for
master and since this file is branched we no longer need to keep this
template definition in this project.
Change-Id: I2ce00106d232d28380c4405ff3ff5e1d036c81c4
* Change order of default tox envlist in order of likeliness to fail
on a new change (fail-fast strategy).
* Remove pypy from envlist as it was not tested on CI, tox default
set of environment should match CI
* Adds py37 to spot possible breakers like dropping relative imports
Change-Id: I4f4abce84f968ff0715abcb5d04fc0014f131fee
This is a mechanically generated patch to switch the documentation
jobs to use the new PTI versions of the jobs as part of the
python3-first goal.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I5d1dd2e123d1fad435dd11ce38952c200e1f26fd
Story: #2002586
Task: #24341
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I30163d1d6dc15f747380860dccb41a3ba1669f00
Story: #2002586
Task: #24341
Create a tox environment for running the unit tests against the lower
bounds of the dependencies.
Create a lower-constraints.txt to be used to enforce the lower bounds
in those tests.
Add openstack-tox-lower-constraints job to the zuul configuration.
See http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html
for more details.
Update the requirement for tripleo-common to reflect reality, and update
the constraint for tenaciy.
Change-Id: Ifdf8dd1c782d6d6ac575d6fd5364dcb083e805a9
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Zuul no longer requires the project-name for in-repo configuration.
Omitting it makes forking or renaming projects easier.
Change-Id: I0bef5348d786c9dcd35e0f03e01df2a6e3270adf
Define the zuul v3 layout for jobs that we want to execute.
Change-Id: I5d421fbcc37b919dcab5f5d3ff6134cdaebab6b5
Depends-On: Ie8aa85fe7a8ee556cc1b46e215d329e95913290c
Alex Schultz