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.
Not sure if it helps you but you can filter out the HoundCI emails by
checking for emails from "Hound <notifications@github.com>”. Also, when a
HoundCI comment is addressed, isn’t the comment collapsed?
I agree though that HoundCI doesn’t seem to work properly. On Katello,
we’ve seen it add inline comments but pass PRs, fail Pos without inline
comments, and raise inline comments that we’re not seeing when running
rubocop locally.
Another reason to move to Jenkins is that sometimes HoundCI doesn’t catch
all the errors that actually rubocop might since it only looks at the lines
changed. Like right now, it doesn’t look like rubocop is passing for
foreman on develop.
David
···
On Wed, Jan 11, 2017 at 11:18 AM, 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.
> 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.
I don't think it did a better job displaying the issues. I do remember
having to point up people to the exact jenkins page where rubocop
failures showed up, as it wasn't immediately obvious what happened.
Inline comments show new contributors what's failing right there.
That was my motivation for using Hound, also Javascript linting and
saving us the trouble of having more jobs in jenkins was also a nice
side benefit
···
On 01/11, Timo Goebel wrote:
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.
I feel actually quite the opposite, we used to have Hound via some
external service and this feels much better integrated. Since github
introduced reviews, Hound integration could take advantage of it in
the future? They will implode once a review is confirmed, that could
help.
On the other hand, we should definitely not insist on all Hound checks
what "community think is a good practice". We have discussed that,
there were flamewars on this topic here already And we did great
job in trying to find the balance. If you have suggestions, just make
a PR with the checkstyle changes.
LZ
···
On Wed, Jan 11, 2017 at 5:18 PM, 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
yes, I find it annoying and I liked the jenkins job more. It would be great if
hound would be able to use reviews that would generate one email per review.
Hopefully they work on it. Otherwise I'd be for moving back to jenkins.
···
On středa 11. ledna 2017 12:07:38 CET David Davis wrote:
> Not sure if it helps you but you can filter out the HoundCI emails by
> checking for emails from "Hound ”. Also, when a
> HoundCI comment is addressed, isn’t the comment collapsed?
Sometimes that’s annoying as well, the the hound comments in collapsed thread.
–
Marek
I agree though that HoundCI doesn’t seem to work properly. On Katello,
we’ve seen it add inline comments but pass PRs, fail Pos without inline
comments, and raise inline comments that we’re not seeing when running
rubocop locally.
Another reason to move to Jenkins is that sometimes HoundCI doesn’t catch
all the errors that actually rubocop might since it only looks at the lines
changed. Like right now, it doesn’t look like rubocop is passing for
foreman on develop.
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.
Hi,
I agree that it is annoying to get a ton of messages from hound every time
a new version of rubocop is released or when they change something in their
default setup.
Hound is working on using the review api but are currently running into
some issues with it: https://github.com/houndci/hound/pull/1262
It is nice to get the comments inline instead of having to go over the
jenkins log to find what didn't work, and using hound also freed up a bit
of the jenkins capacity.
However, I don't have a strong objection to going back to jenkins,
especially if we could prevent tests from running if there are rubocop
errors.
···
On Thu, Jan 12, 2017 at 9:48 AM, Marek Hulán wrote:
Hello,
yes, I find it annoying and I liked the jenkins job more. It would be
great if
hound would be able to use reviews that would generate one email per
review.
Hopefully they work on it. Otherwise I’d be for moving back to jenkins.
On středa 11. ledna 2017 12:07:38 CET David Davis wrote:
Not sure if it helps you but you can filter out the HoundCI emails by
checking for emails from "Hound notifications@github.com”. Also, when
a
HoundCI comment is addressed, isn’t the comment collapsed?
Sometimes that’s annoying as well, the the hound comments in collapsed
thread.
–
Marek
I agree though that HoundCI doesn’t seem to work properly. On Katello,
we’ve seen it add inline comments but pass PRs, fail Pos without inline
comments, and raise inline comments that we’re not seeing when running
rubocop locally.
Another reason to move to Jenkins is that sometimes HoundCI doesn’t catch
all the errors that actually rubocop might since it only looks at the
lines
changed. Like right now, it doesn’t look like rubocop is passing for
foreman on develop.
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
Moving linting back into jenkins will indeed give us better control of
the settings, but it comes with a cost:
higher load on our jenkins slaves - which are already too burdened
at times, leading to slower results.
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, 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
–
Have a nice day,
Tomer Brisker
Red Hat Engineering
Yeah I'm definitely on board with that. The main reason I brought it up is
because Hound is throwing lint errors that I'm not running into locally. I
can't seem to figure out what the difference would be other than something
off with Hound.
Has anyone run into an issue where Hound complains about something that
isn't an issue locally?
···
On Tuesday, November 7, 2017 at 4:58:52 AM UTC-5, Tomer Brisker wrote:
>
> 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, <dsee...@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...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Have a nice day,
> Tomer Brisker
> Red Hat Engineering
>
I've noticed hound failing before without giving me any information as to
why. Rerunning the tests resulted in a happy doggy.
It is nice that hound is able to comment on the PR itself instead of having
to follow the link trail in Jenkins though.
I'm not sure about hound but something like eslint is easy to run locally
using npm scripts before committing.
I see the benefits of each and I would be fine keeping hound but I don't
think we should use hound for JS linting.
Cheers,
Walden
···
On Tue, Nov 7, 2017 at 9:34 AM, wrote:
Yeah I’m definitely on board with that. The main reason I brought it up is
because Hound is throwing lint errors that I’m not running into locally. I
can’t seem to figure out what the difference would be other than something
off with Hound.
Has anyone run into an issue where Hound complains about something that
isn’t an issue locally?
On Tuesday, November 7, 2017 at 4:58:52 AM UTC-5, Tomer Brisker wrote:
Hi,
Moving linting back into jenkins will indeed give us better control of
the settings, but it comes with a cost:
higher load on our jenkins slaves - which are already too burdened
at times, leading to slower results.
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.
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Have a nice day,
Tomer Brisker
Red Hat Engineering
I know there hasn't been much activity here for a while but I'm running
into an issue with HoundCI
<https://github.com/theforeman/foreman/pull/4968#issuecomment-342365167> 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
>
And we did great