GitLab

The windows ci was relying on Qt 5.10.0. This version has a bug that caused
a debug message to be display in some consol.
Also linux and osx are using Qt 5.10.1, so now all os use the same version.

See Qt's bug report for more information: https://bugreports.qt.io/browse/QTBUG-65532

Ui capabilities are required for QtTesting tests

On OSX, qt5 system must be used. This is needed because of the
common-superbuild upgrade.

We can now add locally a new remote and launch the CI with a sha number of this remote

This reverts commit ef5b4b8f.

In the current gitlab-ci setup, the same source directory can be reused.
This can lead the command `git remote add <name>` to fail, and so the ci
pipeline, in case the remote already exist.

This is usefull when we have a public and a private repository of the same submodule.
The public repository of the application will point by default to the public submodule.
But we need to be able to launch the CI from the private submodule.

When creating a new project, the project-level timeout has a default value
of 1h. But the superbuild jobs can take more than 1h to complete, so a
developper will need to MANUALLY change the project-level timeout.
As the job-level timeout can exceed the project-level timeout, let specify
it.

MR !111 modify the CI, to run ctest multiple times. Once for test that can
work in parallel mode, and twice to rerun the failing test in sequential
mode. But the CI was catching the first ctest return code. This first code
was an error as some test aren't intended to run in parallel.
After this commit the test are run sequentially, up to 3 times to pass. Also
the ctest command is only invoke once.

Sometimes, if the ci laptop is under heavy load, some stream test may fail.
To avoid that rerun the failling test one more time.

The SB, used in the CI is shared between all project branches.
It may be interesting to have a custom SB for some branches. This can be
useful when updating the SB for example. This way, the CI continue to work
for everyone on the common SB, but your branch has its own SB.
To do so, SB_BUILD_PREFIX must be defined.

Conceptually configuring and building a project are 2 differrents steps.
Also, having a configure stage will enable you to rerun a configuration
manually before running a packaging manually

Plugins as the VelodynePlugin could only be tested againt LidarView master
by updating them in LidarView and then launching a CI. This process was
very heavy. But for LVCore, in was possible to test them automatically
thanks a LVCore CI trigerring the LidarView CI and updating the module
inside the CI.

With this changes, any submodule could be tested with LidarView master.
The submodule CI need only to trigger LidarView CI, and provide it's SHA
and path, so lidarview can update it before running the CI.

Use before script

Due to a typo, the tar.xf package was never uploaded as an artefact

Currently the ci was ignoring this option because the specify directory
does not exist. Also according to the cmake documentation, this variable
is automatically set based on the SDKROOT environment variable and
CMAKE_OSX_DEPLOYMENT_TARGET.

The ci pipeline status was reported as "Blocked" instead of "Passed"
despite all job beeing successfull. This is a gitlab issue reported here
https://gitlab.com/gitlab-org/gitlab/-/issues/27095

Some useless step where perform, some of which had a performance impact:
* download LFS data (test data) only in test stage
* do not clone in package step, as this will force the next test stage
  to download LFS data again
* do not remove file that doesn't exist in the package step. This is
  because after each job, the package are move and not just copy to the
  CI_PROJECT_DIR, which will clean between each runt.

Before osx and windows had a shell executor whereas linux had a docker.
This leaded to code duplication, as the superbuild stage was very
different.

* remove useless anchor checkout_LVCore

* in build stage: always enable test
* in test stage: do not build but only test
* in package test: rebuild without test before packaging

* merge all rules into one for lisibility
* remove the possibility to run the whole pipeline when schedule

To do so you must define some variable in the project CI settings.
see https://docs.gitlab.com/ee/ci/variables/#via-the-ui

* DISABLE_OSX for osx
* DISABLE_WINDOWS for windows
* DISABLE_LINUX for linux

Currently, per OS, the build dir is share accros all jobs, as there is only one
runnerr for the CI. So to avoid jobs to have parrallele acces to the build dir,
gitlab resource_group functionnality is used.

* Move package stage to the end
* Make build stage independant
* Currently gitlab doesn't has support for conditionnal dependancies
  between jobs, see https://gitlab.com/gitlab-org/gitlab/issues/30680
  so they when the pipeline is schedule, jobs may not run in order

Gilab introduce the keyword rules, that enable us to combine the
manual and schedule jobs into one job, whichout behaviours changes.

toto

In case the gitlab-CI is configure to only fetch the last n commit, the given SHA for LVCore could not be in the git tree.

LVCore CI will launch LidarView CI, with the updated LVCore

This is needed as the test run are the one installed.

This is related to GIT_STRATEGY that doesn't work as expected.
Need to investigate and open an issue on gitlab if required.

Due to time issue, a quick fix is provided.

This script can be used by lidarview's application to perform a basic CI