Re: CI log verbosity
On Sat, Nov 4, 2023 at 2:48 AM Ingo Klöcker wrote: > On Freitag, 3. November 2023 13:01:26 CET Harald Sitter wrote: > > What are your thoughts on having the CI be less verbose by default and > > instead have an env var or some other toggle to switch into verbose > > mode? > > +1 > > Ideally, the verbose logs would be written to an artifact. Otherwise, it > will > be painful to debug intermittent problems. I think the Craft jobs now do > this > (also in response to insanely verbose output of some builds which made it > impossible to see the actual error). > Unfortunately the test log output is all governed by CMake/CTest so there isn't too much we can do ourselves - not without doing quite a bit of work to read XML files produced by CTest anyway. > > > Specifically I'm talking about the qtlogging rules that are currently > > enabling everything and the kitchen sink. To my mind we should just > > use the default rules by default. > > I find that 99% of the time the output is entirely useless in finding > > what is wrong, if anything it gets in the way because I first have to > > find where the test failure is and then instead of reading walls of qt > > plugin info I will just proceed to reproduce the problem locally > > anyway. > > Full ACK. I'm almost always only interested in finding the error which > caused > the CI job to fail and sometimes in seeing compiler warnings. > > Regards, > Ingo > Cheers, Ben
Re: CI log verbosity
On Sat, Nov 4, 2023 at 1:01 AM Harald Sitter wrote: > What are your thoughts on having the CI be less verbose by default and > instead have an env var or some other toggle to switch into verbose > mode? > > Specifically I'm talking about the qtlogging rules that are currently > enabling everything and the kitchen sink. To my mind we should just > use the default rules by default. > I find that 99% of the time the output is entirely useless in finding > what is wrong, if anything it gets in the way because I first have to > find where the test failure is and then instead of reading walls of qt > plugin info I will just proceed to reproduce the problem locally > anyway. > The current approach to enabling all of the debugging information was adopted a few years back when dfaure was trying to debug some tests. We were back on Jenkins then though, which made it quite difficult to set things yourself, unlike what you can do now with Gitlab CI and a work branch. Behaviour is changed from https://invent.kde.org/sysadmin/ci-utilities/-/commit/67e9aaac0f540005834bd61c60abf01eed01cb12 If anyone would like to propose a set of more narrow, sane logging rules then please send an MR (would suggest that it is wrapped behind a check for whether the logging rules variable is set already though) Cheers, Ben > > Thoughts? > > HS >
Re: CI log verbosity
On Freitag, 3. November 2023 13:01:26 CET Harald Sitter wrote: > What are your thoughts on having the CI be less verbose by default and > instead have an env var or some other toggle to switch into verbose > mode? +1 Ideally, the verbose logs would be written to an artifact. Otherwise, it will be painful to debug intermittent problems. I think the Craft jobs now do this (also in response to insanely verbose output of some builds which made it impossible to see the actual error). > Specifically I'm talking about the qtlogging rules that are currently > enabling everything and the kitchen sink. To my mind we should just > use the default rules by default. > I find that 99% of the time the output is entirely useless in finding > what is wrong, if anything it gets in the way because I first have to > find where the test failure is and then instead of reading walls of qt > plugin info I will just proceed to reproduce the problem locally > anyway. Full ACK. I'm almost always only interested in finding the error which caused the CI job to fail and sometimes in seeing compiler warnings. Regards, Ingo signature.asc Description: This is a digitally signed message part.
CI log verbosity
What are your thoughts on having the CI be less verbose by default and instead have an env var or some other toggle to switch into verbose mode? Specifically I'm talking about the qtlogging rules that are currently enabling everything and the kitchen sink. To my mind we should just use the default rules by default. I find that 99% of the time the output is entirely useless in finding what is wrong, if anything it gets in the way because I first have to find where the test failure is and then instead of reading walls of qt plugin info I will just proceed to reproduce the problem locally anyway. Thoughts? HS
