Open Stack

On 9 July 2015 at 09:08, Sean Dague <sean at dague.net> wrote:

> So I think the issue is that we used to have a manual process (reviewing
> g-r adds), and some automated stuff that happens after that.
>
> Now we seem to have a manual process, that triggers some automatic
> stuff, and requires another manual piece before it all works, then
> automatic bits happen.
>
> That seems to just add a lot more error proneness to this. Instead can
> we make this pip resolve process part of the automated testing so that
> it just fails if upper-constraints is incorrect on the g-r proposal?

It already is to a reasonable approximation.

Specifically:
 - we make sure the new g-r can be compiled successfully (see
tools/integration.sh).
 - we make sure the new upper-constraints.txt and g-r are mutually
compatible (see openstack_requirements/tests/test_integration.py)

> I guess I'm missing the part where that has to be done as a second job
> submission instead of at the same time as the g-r proposal.

I think people *should* generate it locally and include it.

We can't fix-it-for them (because we can't change the commit in CI, it
has to come in well formed).
We can't require that CI finds the *same result* because noone would
ever be able to land anything - the landscape moves too fast for our
review latency.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud