Add Clang to CI/CD builds

[wanderingbort]

[transferred from legacy agenda on behalf of @linh2931 ]

(Should we) add Clang build (compile only) to CICD?

Example of issue with status quo: Lambda capture of structured binding compiles in GCC but not Clang in ‘C++17’ mode. Example: https://github.com/AntelopeIO/leap/issues/703

[wanderingbort]

[transferred from legacy agenda on behalf of @spoonincode ]

fortunately there is a task to get the pinned builds in CI asap, so that should offer some coverage

[larryk85]

I would be in favor of this.

[wanderingbort]

2.28 meeting notes:

Open Questions:

• Is it clang or is it "pinned builds" That we should aim for?

Voted Issues:

• Use clang as the CI/CD compiler that we build and run ALL tests on? ✅
  • do we maintain GCC as a secondary CI/CD compiler? ✅

[greg7mdp]

If we want to lower our CI usage for leap, I suggest we run the build + tests on only one platform (instead of the 3 ubuntu 18.04 / 20.04 / 22.04) for branches other than main or release/*.

Most runs are for development branches (for commits during the PR review process), so this would lower the CI usage by almost 3x.

This would allow us to add an extra platform (say ubuntu 22 / clang) while lowering costs. So we'd run CI on 4 platforms for main branches, and on two for development branches.

[greg7mdp]

Developers would benefit from having every change validated by two separate compilers, so it would be nice to have that for development branches. I think that that was the purpose of this issue.

The CI performed for main or release/* branches should be a separate issue in my opinion. It should provide as much coverage as possible for the configurations we recommend to our users. If we specify a pinned build, it seems obvious that we should run our CI on it for main or release branches.

[mikelik]

If we want to lower our CI usage for leap

Do we have any CI limit? And where are we standing with current CI usage? Maybe this is question to @arhag

[greg7mdp]

If we want to lower our CI usage for leap

Do we have any CI limit? And where are we standing with current CI usage? Maybe this is question to @arhag

The message from Bart and Yves was that we should not worry about CI costs, there are mostly insignificant, and if they become a problem they will let us know. So cost should not be stopping us from implementing CI if we see benefits to it.

I just wrote the above because I think running the CI on 3 platforms for development branches is obvious overkill (I personally don't see a benefit), so why do it?