Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches

Luis Gomez

This sounds more like my second item, what about the first or third? what kind of upstream patch requires downstream project build? or you think by just building the patch, replacing jars in distribution and running some CSIT we would catch any issue we would see when you build a downstream project?

On Jun 6, 2018, at 8:28 AM, Robert Varga <nite@...> wrote:

On 06/06/18 17:15, Luis Gomez wrote:
Couple of notes here: the "test-<project>-<feature>" framework used to trigger CSIT on a patch only works in Snapshot integrated projects (mdsal, controller, etc…) and it does not build any downstream project apart from distribution.

So this makes me wonder for this and also MRI project like odlparent, yangtools, what kind of patch verification is more useful:

- Build all downstream projects
- Build patch + distribution + run CSIT
- Build all downstream projects + run CSIT (expensive but possible)
My thinking is:
1) build patch
2) download current distribution
3) unpack
4) overwrite existing .jars (yeah, utterly ignoring versions)
5) repack
6) run CSIT

Dirty, but should be very quick & effective -- MRIs are supposed to be
ABI-backwards-compatible after all :)

This will not work with packaging changes (i.e. different set of .jars),
but that should be very very rare.


Join to automatically receive all group messages.