[openstack-dev] [tripleo][ui] Dependency management
Honza Pokorny
honza at redhat.com
Fri Jan 19 18:43:42 UTC 2018
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
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
More information about the OpenStack-dev
mailing list