You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Code standards expectations are by documentation for some project languages, and by automation for others. In cases of the former:
Contributors don't realize they should follow them
Contributors use different versions or settings for tools like formatters
Non-compliant code sometimes gets checked in and merged. When someone later fixes it i.e. by running a formatter, their PR may be inflated with many out-of-scope changes.
Describe the solution you'd like
For all of Go, Java, and Python:
Standards are checked by CI, to address issues 1 and 3.
Development dependency versions and settings (linting and formatting tools) are managed by build automation, to alleviate issue 2.
Try to fail fast for feedback, but without undue friction on development. For Java for example, we complain on mvn test but not mvn compile (nor test-compile). Perhaps better yet, on CI all the linting could be in one dedicated job / GH status check (though a failure should report all problems, not fail one language, fix and push, fail another language…).
How about we just have make lint or make format at the root of the Feast repo? That would be based on hardcoded configuration that everyone can see, and should ideally cover the whole repo (Java, Go, Python).
Is your feature request related to a problem? Please describe.
Code standards expectations are by documentation for some project languages, and by automation for others. In cases of the former:
Describe the solution you'd like
For all of Go, Java, and Python:
Try to fail fast for feedback, but without undue friction on development. For Java for example, we complain on
mvn test
but notmvn compile
(nortest-compile
). Perhaps better yet, on CI all the linting could be in one dedicated job / GH status check (though a failure should report all problems, not fail one language, fix and push, fail another language…).Git hooks could be an optional suggestion.
@woop suggested on #508:
Sounds good to me.
Describe alternatives you've considered
Additional context
#487
#508
The text was updated successfully, but these errors were encountered: