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.

@kislinsk Currently the Dashboard, does not show the error or failed tests if you click on the Number in the table. Is this part of this issues or another one?

Pushed new branch bugfix/T25882-RewriteDashboardScript.

The This build already has a configure error in the CDash log file is triggered because we submit the Configure part twice: for the superbuild and for the MITK-build. However, it seems that this part is only allowed to be submitted once.

Pushed new branch hotfix/T25882-CDash-v2.6.

Here is the currently working script.

I still cannot browse submission results. :/

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

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

Pushed new branch hotfix/T25882-CDash-v2.6.

Pushed new branch bugfix/T25882-CDash-v2.6.

Closing this meta task. Work will be done in targeted tasks.

Blocked by the fact that e071-jenkins is not yet reachable from outside.

Poor man's backup of the settings: 😄

Note that it's only on Linux as it is the only client where I activated tests. I will disable them for now again and we can decide on Wednesday how we want to proceed.

Damn. As long as the test fail we cannot activate the tests, as reviews will never leave draft state.

Seems to work, but mitkPluginGeneratorBuildTest-Release fails.
http://e071-jenkins:8080/job/MITK/job/Differential/job/Linux/220/consoleFull

Activated tests on Linux Differential clients. Buildable is currently running. If it works as expected, I will also activate the tests for macOS and Windows.
{B605}

I agree that we should have debug clients but not as Continuous, as at least on Windows Clients Debug builds are not faster but at least quite some time slower because of very long execution of tests with lots of image pixel access. Nightly clients in debug mode should make sure not to execute package tests as long as we only support release mode installers.

Sorry, did not see your claim, was already working on it. Proposed fix in D308

Seems the reason this passes on all official clients is Debug vs Release. We currently only test release which ignores asserts. Thus, this should be investigated properly by tracing the problem, Windows and Linux are both affected

Uh, I noticed that it is possible to add aliases/workflows to Arcanist, that are sourced from the project repository. Could be a nice way of streamlining some things. I also noticed that there's already an arc feature feature/T12345-bla which boils down to a git checkout develop && git checkout -b feature/T12345-bla.

Pushed new branch bugfix/T27418-DashboardScriptDownloadWorkaround.

We need specific information of the test failures and if they are the same thing.

Diffusion still shows this:

As noted this seems to be a problem only with Ubuntu-18.04 Debug DiffusionAll because of the mentioned error (so the test itself is not wrong for every system). The accumulated test status is passed. I find this an unsatisfying behavior.