# Adding a CI build to a Slicer extension

**URL:** <https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857>\
**Category:** SlicerDMRI\
**Tags:** build\
**Created:** [July 28, 2023, 2:52pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857 "2023-07-28T14:52:17Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [July 31, 2023, 2:10pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/21 "2023-07-31T14:10:59Z")

</div>

> [@jhlegarreta](#):
>
> Is there an automated way to keep these in sync?

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](https://github.com/Slicer/Slicer/issues/6434).

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [July 31, 2023, 2:11pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/22 "2023-07-31T14:11:58Z")

</div>

> [@jhlegarreta](#):
>
> An intermediate step would be maybe to mark them as `Advanced` variables or grouped under a `Core` category

I like this idea 👍

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [July 31, 2023, 3:45pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/23 "2023-07-31T15:45:19Z")

</div>

> [@jhlegarreta](#):
>
> I have good reasons to set up a CI on GitHub for the extension at issue.

Just curious, does the [nightly build of the SlicerDMRI extension](https://slicer.cdash.org/index.php?project=SlicerPreview&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=SlicerDMRI) 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

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [July 31, 2023, 4:50pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/24 "2023-07-31T16:50:03Z")

</div>

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](https://gitlab.com/opendose/opendose3d/-/pipelines) set up on gitlab.

---

<div class="post-metadata">

**Author:** ![jhlegarreta](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jhlegarreta/32/66542_2.png) [@jhlegarreta](https://discourse.slicer.org/u/jhlegarreta)\
**Post date:** [July 31, 2023, 7:00pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/25 "2023-07-31T19:00:44Z")

</div>

> [@jamesobutler](#):
>
> Just curious, does the [nightly build of the SlicerDMRI extension](https://slicer.cdash.org/index.php?project=SlicerPreview&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=SlicerDMRI) 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

Andras has already stated the point in [his answer](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/24), 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.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [July 31, 2023, 8:24pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/26 "2023-07-31T20:24:00Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jhlegarreta](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jhlegarreta/32/66542_2.png) [@jhlegarreta](https://discourse.slicer.org/u/jhlegarreta)\
**Post date:** [July 31, 2023, 8:34pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/27 "2023-07-31T20:34:29Z")

</div>

Thanks for understanding James.

> [@jamesobutler](#):
>
> This primarily being because developers likely test on one platform say Windows, but then their changes break things on macOS or Linux.

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.

> [@jamesobutler](#):
>
> Are you planning on setting up CI builds for Linux, macOS and Windows?

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

---

<div class="post-metadata">

**Author:** ![jhlegarreta](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jhlegarreta/32/66542_2.png) [@jhlegarreta](https://discourse.slicer.org/u/jhlegarreta)\
**Post date:** [August 1, 2023, 12:37am UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/28 "2023-08-01T00:37:58Z")

</div>

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](https://github.com/Slicer/Slicer/blob/079b3432d5e94465b658080cbce0bf077dbd28de/Extensions/CMake/SlicerFunctionExtractExtensionDescription.cmake) 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 ?

---

<div class="post-metadata">

**Author:** ![jhlegarreta](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jhlegarreta/32/66542_2.png) [@jhlegarreta](https://discourse.slicer.org/u/jhlegarreta)\
**Post date:** [August 1, 2023, 12:51pm UTC](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857/29 "2023-08-01T12:51:44Z")

</div>

Last two builds are passing:  
[Actions · jhlegarreta/SlicerDMRI · GitHub](https://github.com/jhlegarreta/SlicerDMRI/actions)

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](https://github.com/SlicerDMRI/SlicerDMRI/pull/172)

Thanks for all the pointers and thoughts.

[Previous page](https://discourse.slicer.org/t/adding-a-ci-build-to-a-slicer-extension/30857.md?page=1)