Update on Build factory status

Hello all (@lassoan @jcfr @pieper) :

Mac and Windows builds have been failing for the past few days, without obvious errors.

Example: http://slicer.cdash.org/index.php?project=SlicerPreview&date=2019-08-21 - Windows build

This appears to be due to the tests, which are all running to the timeout of 900s. Logging into the factory machines through VNC (both mac and windows) show the tests hanging on the directory chooser for a new/existing DICOM database. Linux is building with no issues (because no tests). They eventually finish, (see mac above which eventually packaged), but far later than is feasible for a nightly build.

I have forced packaging / extension builds for both platforms, so reports should be coming up on CDash for that. Windows packaging is failing with this error, which i will work on sorting out today:

1>CUSTOMBUILD : error EndUpdateResourceD: /D/P/Slicer-0-build/Slicer-build/Slicer.exe [D:\D\P\Slicer-0-build\Slicer-build\Applications\SlicerApp\SlicerUpdateLauncherIcon.vcxproj]

Edit - error was due the open Slicer.exe’s in the background as the tests attempted to run. Windows package should be up shortly.

Eddit: Package link isn’t coming up on CDash: http://slicer.kitware.com/midas3/item/454544


Thanks for all the digging!

Commit r28452 from @cpinter was intended to address this.

It turns out that the popup leading to the timeout is the following:


Last commit updating the source code responsible to display the dialog was https://github.com/commontk/CTK/commit/313e2f98c

Here is where ctkDICOMBrowser pops that dialog:

@cpinter I think you have fixed this (or a very similar) error. Could you check this? Thanks!

The tests passed for me, but maybe I didn’t clear the ini file. I’ll check again.

I manually removed the files and updated the dashboard scripts to ensure settings files are cleared every day.

1 Like

Tests still timing out (whole test suite taking >20hrs):


This should hopefully be fixed by r28464

Looking at today dashboard, I confirm the issue is fixed.


Thanks a lot! Sorry I didn’t get to it sooner; working on refactoring the model hierarchies, and the way hierarchy visibilities are handled. You’ll see a PR soon :wink:


The workaround I added is incomplete and not working.

I think a proper fix would to initialize ShemaUpdateAutoCreateDirectory using settings like it is already done here for schemaUpdateOption. This would allow us to initialize the settings once without having to set the dicom browser property each time a browser is instantiated …

Failing to do so end up triggering the showing of this dialog asking the user to Choose existing database / Select empty folder for new DICOM database.

Will be waiting today’s dashboard to complete to have a better idea of the test triggering a timeout

1 Like

It seems that there are still problems with the factory. There is no Windows package today; certain extensions are not available for yesterday (e.g, SlicerJupyter is missing).

@cpinter Could you look into improving ctkDICOMBrowser by adding a settings for ShemaUpdateAutoCreateDirectory ?

Yes I will take a look at this tomorrow.


I created a PR: https://github.com/commontk/CTK/pull/884

One question that I have is what should be the default. I changed the default to true, so that the tests pass with a clean settings. In this case we’ll need to commit a fix in Slicer that changes this flag to false if Slicer is not in testing mode (DICOMWidgets.py:100)

Thank you @cpinter. I find selecting an appropriate parent folder and creating a new empty folder is not very easy, so it would be great if we would do this for the users automatically by default (but have the option of setting a custom folder location and having the option of starting with a clean database or a copy of the old one).

Is it expected that database update is initiated immediately when Slicer is started (and not when you go to the DICOM module)?

It only happens when the user opens the DICOM browser.

I can confirm that I opened a recent Slicer nightly and it automatically made a SlicerDicomDatabase folder in my user documents location. I did not open the DICOM browser, but it must’ve instantiated an object on load.

1 Like

I see. To me this is unexpected. I will investigate why this happens. Thanks!