Link with CDASH

Summary

This MR is introducing a new widget to link CI build with the corresponding build summary in CDash.

Rationale

GitLab console is less clear than build summary of CDash, and in term we will have the test in GitLab and it will be nice to have sum up in CDash.

Implementation Details

This feature is implemented in python in the file cdash_handler.py. Tests have been added in the CI/test folder.

Basically we look for a file Configure.xml in the build tree (under the sub-directory Testing) to retrieve the needed information to query the buildid in CDash and then build the URL that we put in a new job in GitLab-CI.
For now what we choose is:

• this job is always passing
• the job name will be prefixed by cdash

You can have a look at the result on this MR.

Copyright

The copyright owner is CNES and has signed the ORFEO ToolBox Contributor License Agreement.

---

Check before merging:

• All discussions are resolved
• At least 2 votes from core developers, no vote.
• The feature branch is (reasonably) up-to-date with the base branch
• Dashboard is green
• Copyright owner has signed the ORFEO ToolBox Contributor License Agreement

changed milestone to %7.0.0

added 1 commit

• 8ca1c829 - Restore CI

Compare with previous version

Great! One question: now that we now how to have a link from merge request gitlab page to cdash, is there a way to display it in gitlab in a more explicit way ?

Unfortunately I don't think so... There is work ongoing in GitLab so that we will make link clickable in GitLab console (Issue 33039). Other than having a new widget containing link, status and name I do not know any other way to display it.
We can still replace the link in the job itself, but then we will loose the link to GitLab console.

Maybe we could do the following:

• On submission side, add some sort of grouping using the branch name instead of a plain random build id (for example generate build id that looks like branch_name_random_idr)
• On gitlab issue template, use branch name to generate a link to a filtered dashboard where all builds matching the naming pattern are shown.

This would of course be in addition to what you already did in this MR, which is neat.

On submission side, add some sort of grouping using the branch name instead of a plain random build id (for example generate build id that looks like branch_name_random_idr)

We can do that, for now the submission name is "(short_SHA1) branch_name" but we can change it to "branch_name (short_SHA1)". Buildid is something that we cannot control, it is create upon submission by cdash.

On gitlab issue template, use branch name to generate a link to a filtered dashboard where all builds matching the naming pattern are shown.

I'm afraid it is not possible... Cdash api is quiet poor (CDash API) and even if we could generate a filter we will have the result as a json... Not a web interface...

I managed to achieve the latter without much difficulty:

https://cdash.orfeo-toolbox.org/index.php?project=OTB&date=2019-03-29&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=1649-application-engine-refactoring%20to%20develop

This links to all build name containing 1649-application-engine-refactoring in build name appearing on 2019-03-29.

I created this link by going to cdash otb main page, clicking on the upper right wheel, clicking on Show filters, and then setting the match expression to be Build name contains 1649-application-engine-refactoring, the clicking on Create Hyperlink button.

I do not like putting some experimental code like this in CI, but feel free to add it to this MR or an other!

it's not even code, just an url to customize ... And I did not intend to put it in the ci script, but in the merge request template, which is almost unrelated to CI.

But anyway I do not like the fact that those buttons are always green. An external user has no chance to find the dashboard output, she will click on the red buttons and go to the gitlab-ci output. If you can make them red when tests or build is failing, it will already be better.

@aregimbeau this is what I had in mind : !446 (closed) . We should have done this for months ...

Why is the job always green? Shouldn't it by passing if and only if builds and tests passed?

mentioned in merge request !446 (closed)

+1 to change the status.

Regarding the build name, I proposed some modifications in !449 (merged).

I suggest we close !443 (merged), !449 (merged) and !446 (closed) and merge them into a single new MR to provide a clear picture.

I closed !446 (closed) because it is not really useful for new CI (it would have been for our daily testing, too late).

Even if it has been suggested in this MR, I am not sure there is a link between !443 (merged) and !449 (merged), and !443 (merged) is small. Lets merge it and try to make buttons red when dasbhoard is broken.

@jmichel sorry I though you wanted to add this in the widget... About the status it can be changed to the build status. I'll make the change.

Can it be changed to the test status?

I mean the same as dashboard status. So failed if tests or build are failing and passed if everything is good.

ok, sounds good!

added 71 commits

• 8ca1c829...000ea3ff - 68 commits from branch develop
• 0c96eda1 - CI: add state handling
• c053fb81 - Merge branch 'develop' into link_cdash
• 22aad961 - CI: change name of build

Compare with previous version