GitLab

Sometimes the functional tests are failing, and we still want to access the review environments.
See #2712.

See #2630.

Some of the scripts are highly linked to the algorithm (however not all of
them).

Fixes #2636

See vdj#386.

See vdj#386.

See vdj#386.
We use the same stages for browser and algorithm, I'm not sure this is a good practice.
See also #1491.

See #2496.

Fixes #2496.

See #2496.

See #2496.

See #1847.

This reverts commit 25c2c31a.

See #2403

With duplicate job names only one of the duplicate will be run. This
prevented the review environments to be deployed.

Deploy to $PROD_CLIENT_SERVER where the SSH config is as is:

Host app.vidjil.org
        StrictHostKeyChecking no
        UserKnownHostsFile=/dev/null
        User = bonsai-ci
        IdentityFile = ~/.ssh/bonsai-ci

For web application features that target both ther client and the server

I'm not sure that's necessary, but I prefer having consistent restrictions for
the two environment-related jobs.

This is not really documented but it seems that removing the prefix prevents
Gitlab from realising that an environment has actually been deployed.

See vdj#370

Taken from the Jenkins Vidjil-browser-functional job

As server configuration may change depending on server, the SSH client was
configured directly on the server rather than on the .gitlab-ci.yml file.

Example:
Host vda.vidjil.org
        StrictHostKeyChecking no
        UserKnownHostsFile=/dev/null
        IdentityFile = ~/.ssh/bonsai-ci

According to the documentation <https://docs.gitlab.com/ce/ci/yaml/#stages>:
“Jobs of the same stage are run in parallel”.

Therefore a stage test_unit seems to make sense where all unit tests would be
launched in parallel.