Re: The Future of Boost - CI

From: John Maddock (jz.maddock_at_[hidden])
Date: 2023-05-08 17:40:31

Vinnie,

First of all, let me thank you for taking the time to write all this up, 
and put into words, probably what we've all been thinking!

 >Continuous Integration

CI is wonderful, and horrible!

The main issues I see are that:

a) It needs continual maintenance, as the host runner upgrades/changes 
the systems they support.

b) Stuff breaks without notice because we never know when the hosting CI 
service will change something.

c) Knowledge of fairly obscure scripting is required to make the most of it.

Strictly IMO, the issues that Robert Ramey was complaining about in CI 
recently were due to the above rather than anything wrong with the 
concept, or indeed Boost.

So... in my ideal world Boost CI would look something like this:

* The library author does nothing more than list (maybe in json or 
something similarly popular) the systems they want to test on - and 
these would be abstract Boost-wide names like "core", "bleeding edge", 
"legacy-msvc" etc.  Exactly what these map to would be defined 
elsewhere.  But the point is that now, library authors would almots 
never need to update their CI script *and* all Boost libraries get 
tested on the same "core" which would also form our release criteria.

* Updates and changes to CI would be announced here first, if in doubt 
new compilers *might* go in "bleeding-edge" first and "core" a release 
later.

Machine time could well be donated by volunteers and perhaps replace the 
current test/status matrix, which is fine, but requires you to go off 
seeking for results, which may or may not have cycled yet.  Plus that 
matrix relies on a "build the whole of Boost" approach which 
increasingly simply does not scale.

I'm hoping that approach might even allow us to diversify our testing 
somewhat - to pick a random example - Intel used to be very generous in 
proving us with compiler-licences to test with, but these are sadly 
incompatible with CI, but I suspect they would be compatible with 
individual testers acting as CI hosts though. I'm sure there are other 
examples: MSVC/GCC/Clang are not the only games in town.

Best, John.