Disable CI for the private repository

[tcojean]

This PR disables the CI for the private repository in order to remove the now lengthy redundant jobs.

This is done by using a variable acting as a tag to specify if the CI should be run or not. By default, on the public CI repository that tag is set, hence all jobs are always ran. For the private repository, no jobs will be ran by default, except for the sync job for the master or develop branches.
To run jobs on the private CI, one needs to explicitly create a new pipeline and pass in as variable RUN_CI_TAG = 1.

To ensure it works, I pushed a commit on the private repository, which you can find here. As you can see, no CI was ran for this commit.

[thoasm]

LGTM!

[codecov]

Codecov Report

Merging #539 into develop will decrease coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #539      +/-   ##
===========================================
- Coverage    89.13%   89.10%   -0.03%     
===========================================
  Files          276      276              
  Lines        17877    17884       +7     
===========================================
+ Hits         15935    15936       +1     
- Misses        1942     1948       +6     

Impacted Files	Coverage Δ
omp/components/format_conversion.hpp	40.00% <0.00%> (-60.00%)	⬇️
include/ginkgo/core/base/composition.hpp	89.28% <0.00%> (-3.31%)	⬇️
core/base/extended_float.hpp	93.40% <0.00%> (+1.09%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f04da13...74ded7f. Read the comment docs.

[upsj]

The last CI-related PR #538 seems to have introduced a rather severe issue: For some reason, the nproc evaluates to 4 on both amdci and fineci, effectively limiting our CI jobs to single-core builds again. When I execute nproc manually in the container, it prints the correct 40 and 24, respectively.
Also, an unrelated issue: the Sanitizer builds seem to build with maximum parallelism, since they are executed by CTest, where the CTestScript.cmake sets the amount of parallelism to the number of cores (that's also where the >100 load numbers came from)
I would propose to unify this by setting global per-machine variables CI_PARALLELISM and CI_LOAD_LIMIT that are used everywhere. This way, we can adjust the build parameters without having to edit the CI config every time.
Can we maybe put this all together into this PR?

[tcojean]

There is now a new commit. It fixes the parallelism and load issues.

This is done by using two new environment variables:

• CI_PARALLELISM, the number of cores available per CI job.
• CI_LOAD_LIMIT, the maximum authorized load limit (total number of
  cores on the machine).

Both of these are set in the respective /etc/gitlab-runner/config.toml
for each machine, in the [[runners]] section. See:
https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[yhmtsai]

LGTM