Yetus should be accessible outside pull requests about eve

[ckzed]

One easy workaround is to install the tools that yetus uses internally (revive, shellcheck, hadolint, pylint) in your development environment. There are editor plugins, modules, packages which can be added which show one the errors/warnings as you type. Regards, Chirag Kantharia.

…

On 10 Aug 2019, 12:13 PM +0530, cshari-zededa ***@***.***>, wrote: Please implement a way to run Yetus checks on our code changes before we create a pull request. Right now, we submit a PR, and then come to know about Yetus errors as part of the checks. We end up wasting circleCI bandwidth in iterating over Yetus failures, and becomes a time hurdle in code reviews. What would be good is to have a way to run Yetus on our local EVE repository, so that we can validate Yetus in our laptop before we even create a PR. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[cshari-zededa]

This approach will not work. How do we make sure everybody runs the same set of checks and they are in sync with the Yetus configuration? Thanks Hari

…

On 10-Aug-2019, at 7:21 PM, Chirag Kantharia ***@***.***> wrote: One easy workaround is to install the tools that yetus uses internally (revive, shellcheck, hadolint, pylint) in your development environment. There are editor plugins, modules, packages which can be added which show one the errors/warnings as you type. Regards, Chirag Kantharia. On 10 Aug 2019, 12:13 PM +0530, cshari-zededa ***@***.***>, wrote: > Please implement a way to run Yetus checks on our code changes before we create a pull request. Right now, we submit a PR, and then come to know about Yetus errors as part of the checks. We end up wasting circleCI bandwidth in iterating over Yetus failures, and becomes a time hurdle in code reviews. > What would be good is to have a way to run Yetus on our local EVE repository, so that we can validate Yetus in our laptop before we even create a PR. > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#183?email_source=notifications&email_token=ALXSTFL2Z4NRU6JLESVO3RLQD3BXHA5CNFSM4IKYXOI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AN5TQ#issuecomment-520150734>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALXSTFIMMBAQR7ZRJWD3DYTQD3BXHANCNFSM4IKYXOIQ>.

[rvs]

@cshari-zededa two points, first of all, you can run yetus easily on your own. Just follow the same steps outlined in our .circleci config yaml https://github.com/lf-edge/eve/blob/master/.circleci/config.yml#L46

Also, personally I have no problems with using PR mechanism to run yetus -- sure your first PR is likely to fail, but that's not that big of a deal and you can always follow up with a change that takes care of yetus feedback. Personally -- even though I can run yetus locally -- I'm tool lazy to do that and just use PR mechnism.

[deitch]

I can sympathize here. If I have to wait for a PR test run to report success or failure, it is going to slow down dev cycles. That has led to my personal preference (not always realistic, but preference nonetheless) for my CI config files to always do make <something>, so that I can run the same thing locally just as easily.

Can we perhaps have a docker image built that contains everything yetus needs (auto-correct keeps changing that to "fetus", which is odd - "contains everything fetus needs"?), so that both circleci and a normal user can just run make ci or even make yetus and get the exact same output quickly?

[rvs]

I can sympathize here. If I have to wait for a PR test run to report success or failure, it is going to slow down dev cycles. That has led to my personal preference (not always realistic, but preference nonetheless) for my CI config files to always do make , so that I can run the same thing locally just as easily.

I actually don't get it: for me this is the other way around -- PRs are cheap and fire-and-forget. I typically work on a few issues in parallel anyway so while one PR is testing I can spend time doing something else. In fact, this is much easier than to try and run things locally. Once yetus posts its feedback on a PR -- fixing it is typically super straightforward as well.

Can we perhaps have a docker image built that contains everything yetus needs (auto-correct keeps changing that to "fetus", which is odd - "contains everything fetus needs"?), so that both circleci and a normal user can just run make ci or even make yetus and get the exact same output quickly?

We already have that container and how to run it specified in a circleci config. If you want to hook it up to Makefile -- sure that'd be fine, but personally I have no need for it so it'll have to be one of you guys actually doing the work ;-)

[deitch]

I actually don't get it: for me this is the other way around -- PRs are cheap and fire-and-forget. I typically work on a few issues in parallel anyway so while one PR is testing I can spend time doing something else

Different strokes for different folks and all that. :-)

[deitch]

We already have that container and how to run it specified in a circleci config. If you want to hook it up to Makefile -- sure that'd be fine, but personally I have no need for it so it'll have to be one of you guys actually doing the work ;-)

Consider it done. If it makes life easier for some people, happy to see it done. See #185

[zach-welch-timesys]

FWIW, a make yetus rule got added when #195 was merged, so this issue may deserve to be closed. There may be some bugs with the implementation, but those probably should be filed as new issues.

[deitch]

Agreed. If there are bugs, they should be under new issues. If the way to run it isn’t sufficient, then we need a new issue describing such improvement.

Closing.