On Fri, Dec 14, 2018 at 11:32:00PM +0000, Jeremy Stanley wrote:
On 2018-12-14 17:20:05 -0500 (-0500), Mike Bayer wrote: [...]
OK, so first step is...identify some zuul jobs? I have CI for sqlalchemy, alembic, dogpile-cache that each would benefit from db /cache-centric builds.
I mean, if there's a job which was failing immediately after the release in our CI system and we think that's a reasonable integration test to perform, we could work out a way to have it install dogpile from the master branch source instead of a released package.
I would suggest we use the nodepool-functional-py35-src jobs. These jobs are failing [1] These jobs install a devstack environment, then nodepool, openstacksdk, diskimage-builder and glean from git; then they build an image with dib, upload it to the devstack cloud and ensure it boots and communicates. This means openstacksdk (and hence dogpile) is being used by nodepool against a real-life cloud doing very real-life things like creating servers, listing them and connecting all the various bits up. Connecting to dogpile's gerrit as 3rd party CI is possible. But I'd suggest we KISS to start with. As mentioned above, cloning from github master during the job is a good place to start, as I'm not sure at this point if devstack correctly handles installing non-openstack dependencies from Zuul checkouts during test runs. Reviews: https://review.openstack.org/625467 Add github dogpile.cache to project list https://review.openstack.org/625457 [wip] Add dogpile.cache master to the -src tests -i [1] http://logs.openstack.org/55/624855/3/check/nodepool-functional-py35-src/c63...