CI: Test build for all supported client versions.

[mserajnik]

🍰 Pullrequest

This extends the existing test workflow to build for all currently supported client versions (instead of just 1.12.1) with each compiler (GCC, Clang, MSVC) which will help to prevent compilation errors that affect specific client version builds such as this one.

Proof

• None

Issues

• None

How2Test

• None

Todo / Checklist

• None

[ratkosrb]

Won't this overload the CI cause it's too many builds?

[mserajnik]

20 jobs can run at the same time. Since there are 21 24 (as support for 1.5.1.4449 got added) here now, plus the jobs from the other workflows, some won’t start immediately, but only after others have finished.

So, yes, this will increase the overall time each set of workflow runs takes; imo that tradeoff would be worth it, considering there usually aren’t that many PRs/commits at once that would exhaust the available CI resources.

[0blu]

@mserajnik Just as an inspiration for your next PR: can you take a look at removing TBB from the GitHub workflows?

[0blu]

I mean we are not paying the bills for the server, soooo as long as GitHub allows those kinds of CI's, why not?

[mserajnik]

@mserajnik Just as an inspiration for your next PR: can you take a look at removing TBB from the GitHub workflows?

Sure, I didn't notice it didn't get removed from the workflows yet.

I wanted to do some action updates anyway with the upcoming Node.js 20 removal. I'll remove TBB then too.

[mserajnik]

I wanted to do some action updates anyway with the upcoming Node.js 20 removal. I'll remove TBB then too.

I'm changing this PR to a draft for now while I work on that (since it will need rebasing anyway).

[mserajnik]

I've rebased this on top of 3e54ff3.

I mean we are not paying the bills for the server, soooo as long as GitHub allows those kinds of CI's, why not?

One other option would be to run the additional client version builds only for PRs, and keep only 1.12.1.5875 on development pushes, as it is today without this PR.

That still would have caught these three issues before #3225 was merged:

• Fix 1.5.1 build. #3308
• Attempt to fix Clang build. #3310
• Fix 1.9.4 build. #3311

So this would preserve most of the value without adding a large number of mostly unnecessary builds to every development push, assuming direct pushes to development (not coming from a PR merge) are not expected to introduce those kinds of build regressions.

Let me know if you'd prefer that.