As per running periodically , LGTM runs it every Monday. As for who would fix it, LGTM mentions which commit caused the failure and who was the author of it. So i think its the author's responsibility to fix it.
Personally, LGTM list a table that shows how many alerts we caused by which author [ https://lgtm.com/projects/g/apache/geode/contributors:java <https://lgtm.com/projects/g/apache/geode/contributors:java> ] I cleaning up whatever alerts I have introduced into Apache Geode. Regards Nabarun > On Nov 9, 2018, at 2:54 PM, Alexander Murmann <amurm...@pivotal.io> wrote: > > I don't have strong opinions on this, but I am always suspect of CI jobs > that indicate quality that only run periodically. If the job discovers > something that needs improvement who is going to do the work and when? > > On Fri, Nov 9, 2018 at 2:36 PM Kirk Lund <kl...@apache.org> wrote: > >> Well, we could run it periodically such as weekly rather than as part of >> the main pipeline or precheckin. >> >> On Fri, Nov 9, 2018 at 2:32 PM, Aditya Anchuri <aanch...@pivotal.io> >> wrote: >> >>> +1, although I do wonder about the overhead of making PRs increasing more >>> than it already feels like to me as a new contributor (as the person who >>> made the geospatial contribution). If this was a gradle task maybe like >>> spotless? >>> >>> On Fri, Nov 9, 2018 at 2:20 PM Bruce Schuchardt <bschucha...@pivotal.io> >>> wrote: >>> >>>> I'd like to see LGTM run on pull requests. Otherwise I think we're >>>> fighting a losing battle trying to improve the quality of our code. For >>>> instance, we just had a nice contribution of geospatial functionality >>>> that raised 5 alerts, but we only found out about it after the code was >>>> merged to develop. >>>> >>>> LGTM allows that kind of integration but you have to be the repo >> "owner" >>>> to set it up. >>>> >>>> >>>> https://lgtm.com/projects/g/apache/geode/ >>>> >>>> >>>> >>> >>
