Hi there! 🙂

Hi there! 🙂

I found one last hint, about a possible interference with ccache , last try ...

I tried several things again, similar to described above, same situation.

All Differential clients include MITK-ProjectTemplate builds.

I reported the cmakebuilder-plugin issue to Jenkins: https://issues.jenkins.io/browse/JENKINS-65893

Deleted branch from rMITK MITK: bugfix/T28546-macOSCatalina-Boost.

Pushed new branch to rMITK MITK: bugfix/T28546-macOSCatalina-Boost.

We also need to fix the Boost binary build on macOS.

Deleted branch from rMITK MITK: bugfix/T28546-macOSCatalina.

Pushed new branch to rMITK MITK: bugfix/T28546-macOSCatalina.

• For now I will disable SWIG (and PCRE) builds on macOS and require it to be provided (for example via Homebrew brew install swig).
• I already renamed everything in Jenkins, Phabricator, and Git hooks
• The macOS codename extraction can be easily fixed adding the backslash to the extraction regex

Started with Ubuntu 18.04 and 20.04 clients by adding the following script before the actual build. This is roughly what we are doing already in the Dashboard script.

Okay, nice. Last question: You currently have both a PhenotypingRelease and a ClassificationCmdApps configuration. The apps of the latter one are also included in the former configuration. Is it fine to just go for PhenotypingRelease then at the cost of a little larger tarball as also the workbench application is included? @schererj

I gave @schererj and @gaoh rights to start the Kaapana MITK build jobs and to read the configurations: https://ci.mitk.org/job/MITK/job/Kaapana/

• FileConverter: Covered by regular release (see MITK Volume below)
• Phenotyping: https://www.mitk.org/download/kaapana/phenotyping/
• Radiomics: Covered by Phenotyping
• FlowBench: https://www.mitk.org/download/kaapana/flowbench/
• MITK Volume: https://www.mitk.org/download/kaapana/workbench/

Okay, nice. Last question: You currently have both a PhenotypingRelease and a ClassificationCmdApps configuration. The apps of the latter one are also included in the former configuration. Is it fine to just go for PhenotypingRelease then at the cost of a little larger tarball as also the workbench application is included? @schererj

In T28302#220479, @gaoh wrote:

The normal WorkbenchRelease configuration should be even better suited for the future...

+1

In T28302#220475, @kislinsk wrote:

@gaoh

I noticed that the only plugins enabled in the "MitkVolume" configuration are the segmentation plugins. Do you explicitly want to have this "slim" version or is the official WorkbenchRelease configuration more sufficient?

Okay. Currently running the first test with the PhenotypingRelease configuration and tag set to v2021.02. So the file name will be automatically versioned and will appear at https://www.mitk.org/download/kaapana/phenotyping/ once the build succeeds.

I would like to have files versioned / with different names. If it's necessary to have a download link that doesn't change I can help with a script to create a "latest" link, had that for MITK nightlies back in the days

To all: Do you want to version files or do you want to simply override existing old installers when generating new ones (which happens with custom set revisions descriptions as done in a few docker files above)?

I noticed that the only plugins enabled in the "MitkVolume" configuration are the segmentation plugins. Do you explicitly want to have this "slim" version or is the official WorkbenchRelease configuration more sufficient?

In T28302#220185, @floca wrote:

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

Maybe we should then just label it MITK Workbenches to avoid confusion and reduce (redundant) artefacts.

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

Maybe we should then just label it MITK Workbenches to avoid confusion and reduce (redundant) artefacts.

In T28302#220080, @kalali wrote:

Following this, are there some requirements that need to be specified here T28280?

Ah so the idea is not to build it, but to directly use a CI binary.
So MITK flow uses:

# Generate Ninja build script for MITK to build a minimum configuration with apps in Release mode into MITK-superbuild directory
RUN cmake -G Ninja -S MITK -B MITK-superbuild
RUN cmake -S MITK -B MITK-superbuild -D CMAKE_BUILD_TYPE:STRING=Release -D BUILD_TESTING:BOOL=OFF -D MITK_BUILD_CONFIGURATION:STRING=FlowBenchSegmentationRelease -D MITK_CUSTOM_REVISION_DESC:STRING=MitkFlow
RUN cmake --build MITK-superbuild
RUN cmake --build MITK-superbuild/MITK-build --target package 
RUN mkdir /opt/final_package
RUN cp /opt/MITK-superbuild/MITK-build/MITK-MitkFlow-linux-x86_64.tar.gz /opt/final_package/MITK-MitkFlow-linux-x86_64.tar.gz

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

For MITK-flow and MITK-volume I will switch to the new release (release/T28000-v2021.02). It was only on a develop branch, because there were some bug fixes, not yet in a master branch.
But now with the new release...

Following this, are there some requirements that need to be specified here T28280?

Screenshot from the MITK Github page:

Deleted branch from rMITK MITK: feature/T27460-Badges.

Pushed new branch to rMITK MITK: feature/T27460-Badges.

I used the snapshot client configurations as baseline and created Jenkins jobs in MITK/Release. I also extended the Git hook to trigger these jobs. Hard to test, though, as I do not want to temporarily push test tags. Fingers crossed.

@kislinsk anyone from the MITK CI team who could take over?

I understand. :-) Just wanted to give you more options to think about as it is probably only a temporal solution. Sooner or later (currently read "later"), our minimum version requirements won't match again with the OS-provided Qt version. So we cannot run away from it forever I guess. :D

yes exactly, the problem with the scripted version, ist still, that it is necessary to provide credentials. That was fine, as long we were the only ones creating the containers.
The version of @nolden downloading the packages in ubuntu allows others to just build the container, without having to provide credentials at all.

Thank. New command-line interface looks nice, but the challenge is where to put the credentials, especially if you want to put the script open source like in the Kaapana dockerfiles.

As it already works (?) and we will stay at least another year with Qt 5 we can do this. But in general, do you know of the new Qt Installer Framework with command-line interface? It's much easier now to install Qt with a single command and there are a few possibilities to provide credentials if that's an issue. See here for examples: https://phabricator.mitk.org/T27960#214043

It was released a few days before we put our new server in production mode and I already tested it back then but unfortunately already the installation went everything but smooth. So we should give it at least a few more months to mature before we try to upgrade. :-)

Yes. In fact, this task can already be closed as it doesn't work anymore. :-)

This seems to be superfluous if {T27960} works for us.

Deleted branch bugfix/T25882-RewriteDashboardScript.

Deleted branch feature/T25882-MITKOptions.

Pushed new branch feature/T25882-MITKOptions.

Found the bug in CDash. In app/Model/AuthToken.php:51 the "special value" 9999-12-31 23:59:59 is inserted into the database whereas the maximum value for TIMESTAMP is 2038-01-19 03:14:07. Hence the "special value" appears as 0000-00-00 00:00:00 in the database which will trigger the deletion when it is compared with the current date.

Sigh. Just one time I'd like not to stumble over bugs when dealing with CDash. I implemented the authorization, double-checked that the proxy does not throw away the authorization HTTP header, watched the cdash database, and figured out that as soon as CDash is comparing a valid token... it deletes it from the database.

Deleted branch feature/T25882-CDashAuthorization.

Pushed new branch feature/T25882-CDashAuthorization.

As unknown sites are appearing on our dashboard, we should introduce authentication:
https://blog.kitware.com/cdash-authenticated-submissions/

Deleted branch T25882-CDash-v2.6.

macOS MatchPoint errors that are actually just warnings should be fixed now as well. It's a bug in CMake/CTest and the workaround is to use launchers: https://gitlab.kitware.com/cmake/cmake/-/issues/20832

OMG. how should one find this...

I finally found the source of the documentation errors by accident. It was a dot digraph with invalid flat edges between record shapes. I changed the shapes to boxes and it should work now.

I think I fixed the OpenCV Ant issue by updating the volume snapshot for our Ubuntu 20.04 cloud instances to include the environment variable ANT_HOME=/usr/share/ant.

Pushed new branch bugfix/T25882-RewriteDashboardScript.

Deleted branch bugfix/T25882-RewriteDashboardScript.

• MITK_BUILD_OPTIONS for MITK cache vars
• Check why there are documentation errors "lost edge a b" but when I manually "make doc" on the client, it works
• OpenCV somehow seems to trigger Ant errors on Ubuntu only during the first build (problem in Nightlies)
• First time build of MatchPoint triggers many warnings as errors on macOS

Deleted branch hotfix/T25882-CDash-v2.6.

This is part of this issue (actually the main reason). It is already working in my local version but I have to make a few adaptions to get a stable minimum working version for production.