Hi, Moving linting back into jenkins will indeed give us better control of the settings, but it comes with a cost: 1. higher load on our jenkins slaves - which are already too burdened at times, leading to slower results. 2. This removed context from the linting issues which we now have thanks to the github reviews, and most importantly esp. for new comers - they don't see the issue on their PRs, and won't understand why it failed tests on Jenkins until some maintainer points them to it.
In my opinion having linting issues shown immediately on the PR is much more valuable then the higher control provided by running them on our own. This thread started before hound supported github's code review feature and was sending a mail for every line - this is no longer the case, and I find it very helpful the way it works right now. On Tue, Nov 7, 2017 at 5:34 AM, <dseet...@redhat.com> wrote: > I know there hasn't been much activity here for a while but I'm running into > an issue with HoundCI and I'm wondering if there is still some support for > moving our linting task back into Jenkins? I've been working on simplifying > our .eslintrc file to simply extend airbnb as well as integrate a prettier > plugin for more consistent formatting. Before we make these changes we need > to figure out how to call out the lint errors correctly. HoundCI seems to be > giving quite a few erroneous flags on prettier errors. > > > On Wednesday, January 11, 2017 at 11:18:57 AM UTC-5, Timo Goebel wrote: >> >> Hi devs, >> >> I'm usually not very easily annoyed. What get's me started though >> eventually is when things don't work properly. >> HoundCI is one of those things. >> >> My main concern is, that I get an e-mail and/or Github notification for >> every single comment. These can easily be ten or more e-mails. They're not >> grouped as other reviews. >> In addition, the inline comments are very distracting when reviewing a PR >> imho. When the issues are fixed, I'd prefer for the comments to be removed. >> When reviewing a PR, I usually don't care about the style issues. I just >> want to see if there are some problems or if all is fine. >> >> Back in the days, code style was checked by Jenkins. I think, it did a far >> better job in displaying style issues. With the current Jenkins Github >> plugin it believe would be easily possible to show style issues as a >> separate line along with all the other CI checks. >> >> One argument in favor of HoundCI is, that it checks JavaScript style. But >> I think, that can easily be set up in Jenkins as well by running eslint. >> >> Any comments? How do others feel? >> >> Timo > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Have a nice day, Tomer Brisker Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
