[openstack-dev] [tripleo][ui] Dependency management
apevec at redhat.com
Fri Mar 2 22:52:09 UTC 2018
On Mon, Jan 22, 2018 at 9:30 AM, Julie Pichon <jpichon at redhat.com> wrote:
> On 19 January 2018 at 18:43, Honza Pokorny <honza at 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
>> * Native npm jobs
>> * Undercloud integration jobs
>> After the upgrade, the integration jobs went away. Our goal is to add them
>> 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.
Thanks Julie for reminding me of this thread!
I agree we can only build ui-deps package when the review is about to merge.
I've proposed https://github.com/rdo-common/openstack-tripleo-ui-deps/pull/19
which allows us to build the package with the review and patchset
numbers, before it's merged.
Please review and we can try it on the next deps update!
More information about the OpenStack-dev