Adding a CI build to a Slicer extension

Community SlicerDMRI
21

Unfortunately not. The information in the CMakeLists.txt file and the s4ext file are redundant and may not be in sync - see more details here.

22

I like this idea :+1:

23

Just curious, does the nightly build of the SlicerDMRI extension across all platforms using the Slicer factory machines not suffice for the work that you are doing? Are you trying to avoid self-building the extension against a local build tree? Or are you also avoiding committing a change and then having to wait until the next day to see if the build is successful on the Slicer factory machines? Just wondering what development procedures others are using and how to improve things for development of other extensions

24

The standard for CI today is immediate build for pull requests. It would be nice to achieve this for Slicer, too. Currently, most extension developers rely on local builds and the nightly automatic build. The only exception is OpenDose3D, which has CI pipeline set up on gitlab.

25

Andras has already stated the point in his answer, but the idea is to be sure that any commit to the code (in this case, an extension) does not get merged unless (at least) tests are passing. The nightly builds are wonderful, and I am grateful for those of you who have set them up and maintain them, but they do not ensure this (and besides some maintainers, contributors rarely have a look at them, in my experience). This can save many hours of work when trying to collaborate with others, find bugs, etc.

26

Got it. So the desire is to gate keep more to make sure code doesn’t break things prior to integration. This certainly seems more ideal.

For Slicer core and Slicer extensions it has historically been an integrate changes first, then review the build and testing results the following day to see what unexpectedly broke. This primarily being because developers likely test on one platform say Windows, but then their changes break things on macOS or Linux. Are you planning on setting up CI builds for Linux, macOS and Windows?

27

Thanks for understanding James.

A CI running on all three OS, and assuming some essential tests check basic things, this risk would be minimized. A number of things would be discarded at least.

Long-term, ideal goal. Making this work on Linux would already be a first step. The rest can come later.

28

OK, I understand. Thanks Andras. Have gone through the repository, issue and documentation.

A few thoughts:

  • At first, I thought that adding a parser to generate the s4ext file from the top-level CMakeLists.txt file of each extension would be useful, but I see that this is being done here if I’m not mistaken using CMake, the issue then being the extension index repository not containing the same/reliable/duplicate information ?
  • Maybe such parser, e.g. a Python script, could still be useful to keep the information in sync ? It could directly read the extension’s CMakeLists.txt file (so the very same source the above CMake script uses) to populate the s4ext file? Ideally, the script could be executed nightly with a GHA workflow. The caveat would be that two different scripts, within different workflows, would be doing the same job.
  • Otherwise, a nightly run Slicer could push the generated s4ext files to the ExtensionsIndex repository and automatically open a PR if something has changed in the files ? This is maybe doable with little to reasonable effort ?
29

Last two builds are passing:
Actions · jhlegarreta/SlicerDMRI · GitHub

So the PR is ready to be merged:
ENH: Add GitHub actions build, test workflow file for CI by jhlegarreta · Pull Request #172 · SlicerDMRI/SlicerDMRI · GitHub

Thanks for all the pointers and thoughts.