On 19 January 2018 at 18:43, Honza Pokorny <ho...@redhat.com> wrote: > We've recently discovered an issue with the way we handle dependencies for > tripleo-ui. This is an explanation of the problem, and a proposed solution. > I'm looking for feedback. > > Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for > tripleo-ui: > > * Native npm jobs > * Undercloud integration jobs > > After the upgrade, the integration jobs went away. Our goal is to add them > back. > > There is a difference in how these two types of jobs handle dependencies. > Native npm jobs use the "npm install" command to acquire packages, and > undercloud jobs use RPMs. The tripleo-ui project uses a separate RPM for > dependencies called openstack-tripleo-ui-deps. > > Because of the requirement to use a separate RPM for dependencies, there is > some > extra work needed when a new dependency is introduced, or an existing one is > upgraded. Once the patch that introduces the dependency is merged, we have to > increment the version of the -deps package, and rebuild it. It then shows up > in > the yum repos used by the undercloud. > > To make matters worse, we recently upgraded our infrastructure to nodejs 8.9.4 > and npm 5.6.0 (latest stable). This makes it so we can't write "purist" > patches > that simply introduce a new dependency to package.json, and nothing more. The > code that uses the new dependency must be included. I tend to think that each > commit should work on its own so this can be seen as a plus. > > This presents a problem: you can't get a patch that introduces a new > dependency > merged because it's not included in the RPM needed by the undercloud ci job. > > So, here is a proposal on how that might work: > > 1. Submit a patch for review that introduces the dependency, along with code > changes to support it and validate its inclusion > 2. Native npm jobs will pass > 3. Undercloud gate job will fail because the dependency isn't in -deps RPM > 4. We ask RDO to review for licensing > 5. Once reviewed, new -deps package is built > 6. Recheck > 7. All jobs pass
Perhaps there should be a step after 3 or 4 to have the patch normally reviewed, and wait for it to have two +2s before building the new package? Otherwise we may end up with wasted work to get a new package ready for dependencies that were eventually dismissed. Julie > There is the obvious issue with building an RPM based on an unmerged patch. > > What do you think? Is that possible? Any other solutions? > > Honza Pokorny __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev