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

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...

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

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_CUSTOM_REVISION_DESC:STRING=MitkVolume
RUN cmake --build MITK-superbuild
RUN cmake -S MITK -B MITK-superbuild/MITK-build \
            -D MITK_BUILD_org.mitk.gui.qt.segmentation:Bool=ON 
RUN cmake --build MITK-superbuild/MITK-build --target package 
RUN mkdir /opt/final_package
RUN cp /opt/MITK-superbuild/MITK-build/MITK-MitkVolume-linux-x86_64.tar.gz /opt/final_package/MITK-MitkVolume-linux-x86_64.tar.gz

In T28302#220080, @kalali wrote:

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

I think it should be covered by basic requirements: offer automatic upload of tarballs from build scripts / jenkins and serve them via http, possibly non-public, possibly versioned, though for the latter aspect I would always prefer old-school file name versioning for software archives.

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#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.

Ok, so volume will be renamed to Workbench!

@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?

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 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

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.

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?

The normal WorkbenchRelease configuration should be even better suited for the future...
I also renamed it to mitk-workbench in kaapana.

In T28302#220479, @gaoh wrote:

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

+1

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

• 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/

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/

When you start a job, you are asked for a tag. I already built all three jobs for v2021.02. The packages are automatically deployed to the mitk.org URIs mentioned above.

Everyone who knows the secret tokens can also trigger the builds by URI (nice for scripts). For example:

https://ci.mitk.org/buildByToken/buildWithParameters?token=**********************&job=MITK/Kaapana/Workbench&tag=v2021.02

You can view the tokens in the build job configurations on Jenkins.

I suggest to not experiment as the system can be considered to be in production mode.

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 think PhenotypingRelease then should be enough. Thanks for noticing!

I will include them to my containers :)
Thank you very much @kislinsk this really helps!!!