... because the current master should be compatible with the Zed
release of the other projects. This effectively removes testing on
Python 3.6 and only Python 3.8 and 3.9 will be tested.
Python 3.6 and 3.7 are removed form classifiers because these are no
longer supported.
Related-Bug: #1974244
Change-Id: I7fd253cf0c7d09ca3c4ce9b5d069e4c75a985b68
This removes tripleo-build-containers-jobs as this only contains
centos-7 jobs [1] and they are being removed with [2].
[1] 15761b77d9/zuul.d/build-containers.yaml (L119-L127)
[2] I70d2e5dbe995bc8dfe06817d6460f3f2f3732e7e
Change-Id: I19d8f1c0b9f6d4cfe8cbf98e86cea51c76ff369b
Because the Xena release is not being created for TripleO repos, test
runtime is not updated by automation tools. This change updates
the job template to use the tested runtime for Yoga.
Change-Id: I3c746be9ddb8d6e8a310071ba2f5be54e732d356
The rt-kernel image has been converted to an
overcloud-hardened-uefi-full version. All others are deleted as
they're already replaced by the overcloud-hardened-uefi-full image.
Blueprint: whole-disk-default
Change-Id: I5dfcf4dfa66be57ee3a6f94e1a094dcd527ffac5
The upgrades template was commented out to get
a change through that fixed failing content providers.
This template can be added back when the two
relevant release content provider jobs are
passing again.
Change-Id: Ib5f955d9df1b66125b20cbf7363779abd3e0d12a
Also install centos*release package when tcib_distro
is centos.
*release packages are protected by dnf, so used
rpm commands to remove.
Disable upgrades pipeline to get this fix in.
Closes-Bug: #1939674
Change-Id: I5467a5faa36aa1359ff9b8135a512566dff12a79
tripleo-buildimage-overcloud-hardened-uefi-full-centos-8 has the same
dependencies as tripleo-buildimage-overcloud-hardened-full-centos-8
Blueprint: whole-disk-default
Depends-On: https://review.opendev.org/c/openstack/tripleo-ci/+/788878
Change-Id: I4aef31ea2e2f5665e63cb2dae598428d4654b0ca
As part of [1] this removes the unneeded zuul layout overrides.
All the jobs removed here are already included with the relevant
templates. The files: matches that were used for the scenario
standalones are moved to the template layout via the depends-on.
The build-containers-ubi8 job is not needed as it is exercised
by the content providers and we have removed this job from other
tripleo layouts.
[1] https://review.opendev.org/q/topic:tripleo-ci-reduce
Depends-On: I633bc01bc1a8cd8d1216e503eaa9a43aef9a7fa0
Change-Id: I95efa61361882875505e5e359dece23a5a67bfc9
This wires up the tripleo-buildimage-jobs and updates buildimage
job overrides in the check layout. The depends-on adds the
files: matches in the template layout so no need to override here.
The gate layout overrides are removed altogether as we don't want
the dependencies: optimization in the gate. Part of wider tripleo-ci
optimization [1].
[1] https://review.opendev.org/q/topic:tripleo-ci-reduce
Depends-On: https://review.opendev.org/c/openstack/tripleo-ci/+/777083
Change-Id: I24615a067a56ac226b07c2ebcf477b3682dfed2f
This reverts commit 4274d92e78.
Apparently tripleo-ci-centos-8-content-provider is not sufficient
in catching bug like https://bugs.launchpad.net/tripleo/+bug/1909105
So Here adding the tripleo-ci-build-containers-ubi-8 job
in check and gate queue.
Change-Id: Iba5675e37d693664c3b10404c2816f87f294fd6c
This file, and its tests, are not useful for tripleo so we're
removing because they're now becoming problematic.
Change-Id: Id289af99ee20f37ebffe3cefb6bdd65b5d61ca99
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: I51ac2c4ca4c90067b34d2dd71f68e2581f94853c
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: I3fb70478eb3eac31955b75ed591eaa309482a035
When patching the BuildahBuilder, it would be nice to get feedback from
the tripleo-build-containers-ubi-8 job as well, it provides quick
results on how we build the images with Buildah.
Change-Id: I99a05d14373976fb178b8d5822a854ccf786d231
tripleoclient isn't gating on python 3.8 but on python 3.7. In fact,
python 3.8 is still non voting and it seems to be broken for openstack
client as of today:
AttributeError: 'EntryPoint' object has no attribute 'module'
So let's stick to how tripleoclient is tested, which is python 3.7.
Change-Id: I79bbf0eb420cc445cb687f2c5929f634c3c233fc
gnocchi-db-sync requires cradox to be installed if RBD backend is used.
Until we fix it properly in the distgit, let's make sure cradox is in
the base image for gnocchi. It also requires httpd and deps for the
dv_sync to operate when Ceph is installed.
With that patch, we can now test container builds on scenario001.
Change-Id: Id13028ab911ba91d67787ca8247effc02017fcbc
Instead of pulling images from a local registry, build them locally
since the configs that build them are in tripleo-common.
Also trigger the appropriate scenarios if a container config is changed.
Note: this patch will make all standalone jobs running against
tripleo-common to use locally built container images, even if the patch
isn't about a container image config file. It has been found that the
time to build images is roughly the same as the time it takes to update
them once pulled from a remote registry.
Note: scenario001/002 will come later once we figure out an issue with
gnocchi-db-sync and cradox.
Depends-On: https://review.opendev.org/729465
Change-Id: I28d2edd4f923fb2d263df43fff4ef82a4072040c
tripleo-cross-tripleoclient-py38 is a new job that will run unit tests of
tripleoclient master against the current patch on tripleo-common, to
make sure a patch in tripleo-common wouldn't break tripleoclient.
Change-Id: I55505ba6ac2ca3df762b39c73f9e69520f93c638
Only run tripleo-build-containers-ubi-8 if container image configs are
changed.
Depends-On: I50e0b773273910ed7e4884d52106f07003d4e080
Change-Id: Iad94d65487c98fff8f054f0eadc334d7e7c1e4ed
https://review.opendev.org/#/c/736330/ has now added an option
ensure_global_symlinks (default 'flase') which has to be set to 'true'
if we want to use tox from normal path.
ex. 'tox -e linters -- flake8' in pep8 job.
Also ignores basepython conflict in tox.
Change-Id: Ia24678c1fe905d6c526d79f71ea973834074f703
See I6a73f7f22dda69bef324ffdaecdcd6be693c1257 for the whole context
but we are removing OpenShift from TripleO.
Note: the scripts/tripleo-deploy-openshift script hasn't been removed
yet because we need to update the packaging first in
https://review.rdoproject.org/r/#/c/21749 but first it requires the unit
tests to be removed.
Change-Id: Ia64ceb1f05d96d2358509392bb3cbc3b9cb61030
We've excluded most jobs from running if the tox jobs fail but we were
still running the standalone jobs. Let's skip those too if pep8 or the
unit tests fail.
Change-Id: I2a58cd0244aefbe1202f610fcaa9af1f98e5f847
Ease linting by using pre-commit to manage execution of all linters.
That change does not require any changes for user, they still can
trigger the linting using `tox -e pep8`. Also syncs sphinx requirements
with global openstaco ones as these were broken but the check job runs
only when the file is touched.
Change-Id: Ib07e40f1f87a33474ae9412ddf5ba359eb5d5068
These roles have all been imported into tripleo-ansible and can now be removed
from here. Several roles still remain in tripleo-common largely because they
have inflight changes which should be merged prior to doing the conversion.
A follow on PR will be made to clean-up the remaining roles when they're
ready.
The zuul job layout has been udpated to remove the "openstack-tox-molecule"
job. This was done because we no longer need it in this repo; all of
the roles have been moved to tripleo-ansible.
Change-Id: If7f9f2ce6f13d18fd864c475961275c611d84eb6
Signed-off-by: Kevin Carter <kecarter@redhat.com>
while we are adjusting the DIB for el8,
let's trigger the image build jobs until
everything is stable again.
Change-Id: I76345d14c9ec05776e189ea6ed0ad18ce5ac3fb0
Enable testing roles with molecule via tox-molecule job.
Its first version only tried to run tripleo-bootstrap role on two
supported platforms.
Test locally by running `tox -e molecule` or
`pytest path/to/molecule.yml` if you have pytest-molecule installed.
Depends-On: https://review.opendev.org/#/c/663599/
Change-Id: I27157c439aea5ca6bda2e2d9070644ef7bb23a9d
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.
Also adjusted a warning check in the utils.config test due to python3
Also updated requests to 2.18.0 so that the python uploader can use
requests as a context manager which was not added until v2.18.0. See
4847f5b8cd
Change-Id: I78bffdf69113988192afc466d4ce04b3b97e796a
Depends-On: https://review.openstack.org/555034
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Co-Authored-By: Alex Schultz <aschultz@redhat.com>
..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 <bdobreli@redhat.com>
Takashi Kajinami
Marios Andreou
Steve Baker
Ronelle Landy
Sagi Shnaidman
OpenStack Release Bot
Sorin Sbarnea
Bhagyashri Shewale
Kevin Carter
Amol Kahat
Rafael Folco
Emilien Macchi
Rabi Mishra
Hervé Beraud
Wes Hayutin
xuanyandong
Corey Bryant
Alex Schultz
Arx Cruz
Doug Hellmann
Bogdan Dobrelya
confi-surya