[rdo-list] Third party DLRN CI and the need for a "-head" builder
javier.pena at redhat.com
Fri Oct 7 07:29:50 UTC 2016
----- Original Message -----
> So with the help of Paul Belanger, we've identified the issue that
> prevented the "openstack-check-verified" pipeline from working.
> The Zuul openstack-check-verified pipeline  from
> review.rdoproject.org can be used to trigger builds on upstream
> projects on each patchset, only when Jenkins has +1'd it.
> The goal with this pipeline is to do third party CI with DLRN in order
> to try and build projects' patches to warn us for failure to build
> errors ahead of time, even before the change merges.
> We're not planning on voting on the Gerrit changes, it's solely to
> check if there are any issues building the project with that
> particular patch.
> So we really have two Ocata DLRN instances now, one that is pinned to
> upper-constraints  and one that builds the "master of everything"
> I was thinking... If we're able to do third party CI against upstream
> with DLRN do we need that "head" instance ?
> The "head" instance exists, as far as I know, to let us know if
> anything from unpinned projects fails to build.
> The third party CI will let us know that -- and even before, ahead of
> time, before the change causing the failure even merges.
I think we still need the "head" instance, even if it's only used to provide a repo for the third party CI to use when building.
One example: the current python-openstackclient in head fails to build due to a funny interaction with os-client-config . This os-client-config version is not yet in u-c, so if we used the u-c repo to gate, we would never see it in our gate.
We might reduce the build frequency to once a day or so, but we still need that instance.
> Thoughts ?
> : https://trunk.rdoproject.org/centos7-master/
> : https://trunk.rdoproject.org/centos7-master-head/
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> dmsimard = [irc, github, twitter]
More information about the dev