On Thu, Jun 06, 2024 at 06:51:15AM +0200, Patrick Steinhardt wrote: > > I do not mind reverting the topic out of 'next' and actually would > > prefer replacing it with a corrected version, which would allow us > > to merge the clean copy to the next release. > > I wouldn't exactly say prematurely, given that it likely wouldn't have > gotten a review without the merge because it was spurred by Coverity :) > I really wish that the Coverity tooling was available to run at will and > locally in our pipelines so that we can stop reacting to it, but instead > address whatever it flags _before_ the code hits the target branch. But, > well, that's not how Coverity works. Yeah, I'd agree with the analysis here. While somebody _could_ have found these by inspection, in practice it was the merge to next that led me to them. It may imply that we should be running Coverity earlier, though. In my fork I trigger Coverity runs based on my personal integration branch, which is based on next plus a list of non-garbage topics I'm working on. So I get to see (and fix) my own bugs before anybody else does. But I don't see other people's bugs until they're in next. I could try running against "seen", but it's a minor hassle. I don't otherwise touch that branch at all, and I certainly don't want my daily driver built off of it. Plus it sometimes has test failures or other hiccups, and I already get enough false positive noise from Coverity (so even if I ran it, I'd be unlikely to spend much time digging into failures). So what I'd suggest is that you try setting up the Coverity workflow yourself. There are rough instructions in the GitHub workflow file, and I imagine you'd be able to port it to GitLab. Coverity does do SSO login with GitHub, but I don't think it's relevant once you've got an account there. The opaque token they give you is all you need to upload a build. -Peff
