1. Topics
  2. [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches

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

Luis Gomez
 

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)

BR/Luis

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

On 05/06/18 16:28, Sam Hague wrote:
All the projects in the to: list have the ability to run genius and
netvirt csit on any patch using a gerrit comment. The job is non-voting
and only reports back status. If you do run the csit and notice a
non-success, please ping the genius and netvirt lists to look at the job
so the team can fix any issues found.

The format of the comment is:
test-<project>-<genius|netvirt|cluster-netvirt>.

For example, on a controller patch, you would add this comment to run
genius csit: test-controller-genius. This is shown in controller
patch: https://git.opendaylight.org/gerrit/#/c/72650/.

For aaa to run netvirt csit, test-aaa-netvirt.
This is awesome :) although yangtools would also need a replacement of
jars, so I am not sure how useful it is at this time :)

Thanks,
Robert

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Robert Varga
 

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.

Regards,
Robert

?
signature.asc

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.

Regards,
Robert
1 - 3 of 3