On 11/6/23 1:24 AM, John Maddock via Boost wrote:
The CI for the boost serialization does not and never has worked. This is easy to veryify just by looking at any of the CI output for this library. And this demonstrable fact has been pointed out numerous times. This situation is never addressed.
I doubt that the serialization library is the only one with this issue.
The sadist part of all this is that even if it did "work" it would still be useless. It's not uncommon for a large and/or complex library to fail one or more tests on one or more compilers due to issues in the compiler itself. These can't be "fixed" in the library. The test matrix shows all the tests x all the environments. One can easily see if any failure is general or isolated to a particular environment. The current CI just registers pass/fail for the whole library and all the environments. Some times someone will suggest skipping a particular test for a particular library so the CI comes of clean. This is basically hiding the error. Users considering using a library in their own enviroment are basically mislead that their the library works everywhere - which is demonstrably untrue. It's a fraud.
Personally I find that CI works just fine, with one caveat: you do need to update the scripts on a semi-regular basis otherwise you will find lots of useless failures often caused by changes to the host environment outside our control. This of course reflects real world usage.
A typical example - clang on ubuntu jammy just stopped working - the cause was an update of the system default compiler from gcc-12 to gcc-13 which rendered the clang version we were testing non-functional. The solution is to do what you would tell a user to do - update the clang version to one that can handle gcc-13's std lib!
The output of the CI is very user unfriendly.
It's not awful, it's just a dump of the build output
Right - that's awful - just like you get
if you run tests locally. It could of course be better.
I had to write my own library_status program to make sense of it. I've displayed the results on several ocasions to a universally unimpressed audience. Oh well. Of course this doesn't help when displaying CI output.
I just do what I would do for console output and search for "..failed" to find the failures.
I sometimes do that. It's complicated by the inclusion of tests which are meant to fail compile and/or link. And a lot of noise. Its not particularly useful when there is a failure in one environment and not in others - e.g. static vs linked libraries, etc. The test matrix is much, much better for this. Maybe the CI output could be funneled to a program which produces text matrix like output. (oh wait, I'm already doing this!).
Oh and you can download the logs and process them yourself if you want to.
Not all the information required is in the logs. Some of it is in the process jam log program (or ?) Now I don't remember.
The current CI is very slow and consumes a ridiculous amount of resources.
Actually I'm astonished how fast it runs,
actually I only concluded that from the fact that I often receive the CI output hours? / days? after a PR has been submitted. It also runs the whole CI on the most trivial of changes - like removing a space from a comment. Users often submit changes like this. if you haven't updated your
scripts in a while though, it's likely you're using github images which have been deprecated, and will basically never run now (or take a very long time to do so).
Resources, I would agree on.
Best, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost