clang-tidy: fix for empty config.

[KaiSzuttor]

we only have a CI job with maxset and clang-tidy. This PR fixes issues found with empty config.

[KaiSzuttor]

maybe we should replace the image of the empty job and use a clang container and build with clang-tidy?

[jngrad]

I wouldn't mind, as long as the compilation time remains within ~20 min (currently it's 7 min).

[codecov]

Codecov Report

Merging #3202 into python will decrease coverage by <1%.
The diff coverage is 71%.

@@          Coverage Diff           @@
##           python   #3202   +/-   ##
======================================
- Coverage      85%     85%   -1%     
======================================
  Files         530     530           
  Lines       26025   26024    -1     
======================================
- Hits        22158   22157    -1     
  Misses       3867    3867

Impacted Files	Coverage Δ
src/core/observables/MagneticDipoleMoment.hpp	100% <100%> (ø)	⬆️
src/core/observables/Current.hpp	100% <100%> (ø)	⬆️
src/core/observables/DipoleMoment.hpp	100% <100%> (ø)	⬆️
src/core/constraints/ShapeBasedConstraint.cpp	87% <50%> (-1%)	⬇️

---

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 295c398...20a9d23. Read the comment docs.

[RudolfWeeber]

Please only merge before the release if it fixes actual bugs

[jngrad]

bors r+

[jngrad]

bors r-
(another merge fail in the staging branch)

[bors]

Canceled

[jngrad]

bors r+

[jngrad]

@KaiSzuttor we need to investigate GitLab CI on Monday, canceling a bors job and restarting it later will cause a random merge commit to start CI (see latest GitLab pipelines, reproduced below).

Status   Pipeline Commit
-------- -------- --------------------
running  #9620    staging 0b7b3573     <--- real one
skipped  #9619    staging.tmp 987d70e0
running  #9618    staging 128d59c9     <--- from the 2nd `bors r+`, but already in python
failed   #9617    staging 75d4715c     <--- from the 1st `bors r+`
running  #9616    PR-3245 fb3c8fe1
passed   #9614    python 128d59c9

[mkuron]

canceling a bors job and restarting it later will cause a random merge commit to start CI

The problem is that Gitlab doesn‘t (and can‘t) know that a bors job was cancelled. Whenever something is force-pushed to the staging branch, the previously running pipeline is cancelled and one is started for the latest commit.

[bors]

Build succeeded

• ICP GitLab CI

[jngrad]

Whenever something is force-pushed to the staging branch, the previously running pipeline is cancelled and one is started for the latest commit.

Didn't notice it until two days ago. This defeats the purpose of automation. Thanks for the fast reply. I've added a note in our CI documentation.

[KaiSzuttor]

Whenever something is force-pushed to the staging branch, the previously running pipeline is cancelled and one is started for the latest commit.

why? i thought it only gets canceled if the pipeline is not running. at least it was like that before.

[mkuron]

i thought it only gets canceled if the pipeline is not running.

That's the automatic cancellation of redundant pipelines that Gitlab has had for at least a year now. Even if we disabled that (which we shouldn't, because it really reduces the number of pipelines we build on pull requests), one couldn't expect the pipeline to continue after force-pushing to staging because the automatic garbage collection will eventually remove the dangling commit.

This sounds more like a design flaw in bors. It can't reasonably force-push to staging and expect all intermediate pipelines to finish.