search

scenerygraphics / sciview

sciview is a tool for visualization and interaction with ND image and mesh data
BSD 2-Clause "Simplified" License
62 stars 18 forks source link

CI-managed integration testing with scenery #288

Open kephale opened 3 years ago

kephale commented 3 years ago

Every now and then API changes in scenery get introduced ( possibly with a merge of a big feature branch, making it hard to find specific changes ) that break Sciview.

It would be nice if we could setup a hook in scenery/sciview that would at least try building sciview with the corresponding scenery push.

kephale commented 3 years ago

A related concern:

There is a branch of pom-scijava: https://github.com/scijava/pom-scijava/tree/sciview where we are tracking development versions (e.g. jitpack hashes) of scenery and sciview (plus respective changes to other dependencies)

If we are doing an integration tests, then we may also be able to automatically update this pom-scijava branch at the same time

kephale commented 3 weeks ago

@ctrueden @skalarproduktraum do you think we'll end up managing this via melting point in the long run? I'm just trying to avoid reinventing more integration testing tooling.

skalarproduktraum commented 3 weeks ago

@kephale There's a script in the scenery repo that's used to build scenery against its example project. Having the same script for sciview would not be a lot of effort đź‘Ť

ctrueden commented 3 weeks ago

I support that sort of integration test being added to sciview, because scenery is so integral to its operation. Such a script is likely to catch more breakages faster than the pom-scijava melting-pot would, because melting-pot normally only runs on release versions of components when they are bumped in pom-scijava itself.

Nonetheless, I would suggest that you could reuse the melting-pot.sh in the sciview repo to do the test... except that melting-pot.sh is written to use Maven projects, not Gradle ones. It would not be trivial to make it work with Gradle-based projects, especially since the sciview and scenery Gradle builds currently have no mechanism yet to pass version overrides via command line parameters. So adapting the linked script seems like the way to go for now. Eventually, we may start feeling pain not having sciview nor scenery in the melting-pot—imagine other downstream components impacted by scenery or sciview API breakages, for example—at which point we can discuss what to do. Lingering technical debt... but debt that I am not eager to address until absolutely necessary.

kephale commented 3 weeks ago

@skalarproduktraum would it be OK to put a sciview version of that script in scenery? That seems like the simplest thing for now.