EBN Still Needed?

[Volker Krause]

On Thursday, 28 March 2019 09:23:21 CET Ben Cooksley wrote:
> On Thu, Mar 28, 2019 at 6:26 AM Volker Krause <vkrause at kde.org> wrote:
> > On Tuesday, 26 March 2019 21:15:31 CET Allen Winter wrote:
> > > I was notified today that the Krazy runs on the EBN have been stuck (due
> > > to
> > > a stale lockfile) for over 3 months.   Is this an indication that nobody
> > > looks at the EBN reports any longer?
> > > 
> > > I still maintain Krazy and am happy to make modifications, but I don't
> > > see
> > > the point unless someone actually reads and acts on the reports.
> > > 
> > > Note that clazy does replace Krazy on most everything (C++) so it could
> > > very well be that people are relying on Clazy instead of Krazy.
> > > 
> > > This is not about the API dox generation side of things, which of course
> > > we
> > > keep.
> > > 
> > > But has the EBN code and documentation checking service out lived its
> > > usefulness? Shut it down?
> > 
> > I think for the C++ checks it's indeed due to Clazy/clang-tidy
> > outperforming Krazy, both in terms of precision and in runtime
> > performance. And for code I'm working on I usually run these tools
> > locally indeed.
> > 
> > However Krazy is more than C++ checks, and EBN is more than Krazy. I do
> > think it's very valuable to have the infrastructure to do "global" scans
> > on all our repositories, see e.g. the work in D19996 for finding insecure
> > http: links anywhere (code, docs, website content, infrastructure config,
> > etc). Continuous checks in commit hooks or the CI will help us to catch
> > newly introduced issues there, but it wont help in getting this fixed
> > everywhere in the existing repos.
> 
> Couldn't the CI runs produce as part of their output reports which
> would contain historical issues as well as checking to see if the
> state had regressed?
> (Ideally this would be from a state of no issues)

For the repositories checked by the CI this will actually automatically happen 
with the proposed approach in D19996, as that injects the test via ECM.

This will run the "passive" check only and is quite fast (essentially just a 
regular expression). There's also a more elaborate "active" check that 
verifies DNS and TLS for all found URLs, that takes considerably longer to run 
and bothers external servers, so probably not something we want to execute 
continuously. The active check also benefits from (low frequency) re-runs, as 
its failures can be caused by external services finally upgrading to support 
TLS, or going away entirely, even if we have no changes on our side.

Regarding starting from a no issue state, we are unfortunately far away from 
that, despite aggressively excluding things like the license headers. I do 
agree though that enabling this as a unit test via ECM, or in another way on 
the CI for that matter, should not happen before the amount of remaining 
issues is more manageable. I certainly don't want to knowingly switch 200+ 
modules to yellow on the CI ;-)

One aspect I'm not sure yet how to handle best in the CI context are non-code 
repos. We have found a number of http issues in there too, repo metadata is 
one such example, and I'm sure website content would benefit from this check 
too.

If the infrastructure for supporting this is called "CI" or "EBN" doesn't 
really matter to me, I just wanted to point out possible use-cases that go 
somewhat beyond classical build and code checks :)

Regards,
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20190328/aca386b4/attachment.sig>