-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Introduce a coding style for libs
repo
#470
Conversation
* set column limit to `100` * SortInclude must be `Never` not `False` * Disable formatting for other languages, just to be sure Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There seem to be some problems with the permission for issuing comments on the PR, I will try to address them ASAP, by the way, they are not necessary at all, they are just a nitpick 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome @Andreagit97! Thank you very much for implementing it!
@@ -0,0 +1,44 @@ | |||
--- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, yes, 1000 times yes!
- name: Install clang-tools 📥 | ||
uses: KyleMayes/install-llvm-action@v1.5.3 | ||
with: | ||
version: 12.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we using a different LLVM version for clang-tidy
? 🤔
If we can use the same for both? Is there any way we can ensure we will always use the same version? Maybe it can be added as an environment variable to the repository and controlled globally from there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I know, unfortunately, the GitHub action that prints messages in the PR accepts only YAML files containing generated fixes by only some clang
versions :( I used the latest so clang-12
@@ -0,0 +1,80 @@ | |||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are using pre-commit
for checking commits, think it would be worth it to also use it to run the linters/formatters instead of defining custom was of running the tools? We can keep the make targets for ease of use, but I think unifying methods could help reduce potential incompatibilities on silly things like command line flags mismatching.
You can take this as an example if it helps: https://github.com/stackrox/collector/blob/843fbc328028ad6a6cfa0fb281f7f08703c40e65/Makefile#L171-L182
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I just realized you mention this in Contributing.md. I know it's tempting to allow people to choose whichever way the want to use hooks, but in my mind it is still better to unify it since it will likely lead to less problems due to compatibility in the long term. Would love to hear other people opinion on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point! Personally, I prefer to have both methods since we use this makefile also in the GitHub actions... using makefile is clearer we just type the exact command we want, I consider it as the real source of truth. I added the pre-commit
framework to help people who don't want to install these tools with their hands but I don't like too much the approach since you have no full control as in makefile. Anyway, we can discuss that, maybe someone else has some opinion on this 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought on it a little bit and we could also use the pre-commit framework in the CI, at the end it's almost the same thing 🤔 What do you think about it @leogr @deepskyblue86 @FedeDP?
3656845
to
f76234e
Compare
Signed-off-by: Andrea Terzolo andrea.terzolo@polito.it Co-authored-by: Mauro Ezequiel Moltrasio <moltrasiom@hotmail.com>
@Andreagit97 this is awesome, but I'll have the action blocking the merge, or else this could be just wasted effort. nit: several files don't have the newline at the end. |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
I would like to bring this up again |
if we all agree I would move this to 0.18.0 /milestone 0.18.0 |
I agree! We wait a bit long for this one to land 😄 |
Signed-off-by: Andrea Terzolo <andreaterzolo3@gmail.com>
Adding label Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Perf diff from master - unit tests
Heap diff from master - unit tests
Heap diff from master - scap file
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #470 +/- ##
=======================================
Coverage 74.20% 74.20%
=======================================
Files 253 253
Lines 30832 30832
Branches 5402 5387 -15
=======================================
Hits 22880 22880
+ Misses 7943 7924 -19
- Partials 9 28 +19
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
🥳 |
closed in favor of #2038 |
What type of PR is this?
/kind design
/kind feature
Any specific area of the project related to this PR?
/area build
What this PR does / why we need it:
This PR puts in place all the necessary stuff to enforce a definitive code style for our repo. On one side, we provide different simple ways to apply the new style before pushing patches upstream (
Makefile
,pre-commit
framework), on the other, we use GitHub actions to check that the style is enforced before merging the code.The new
Contributing.md
file explains all the new features added, so for more info please take a look at it.Here you can find some additional points:
As @Molter73 suggested I added a way to enforce both the coding style and the
DCO signed-off
through thepre-commit
framework, let me know if it looks good to you! 😄You can find the configuration for
clang-format
andcmake-format
tools in the corresponding configuration files.clang-format
.cmake-format.json
. I used mainly the default configuration for both the tools, plus some little modifications as @deepskyblue86 asked (I set thetabsize
to 4, this seems reasonable to me, but let me know about it)I merged the old
coding_conventions.md
file into the newContributing.md
. I kept only some of the best practices since the others are already addressed by the new code style.I have added a new GitHub action to run static analysis code with
clang-tidy
. This check will run only on files changed by the PR and more precisely it notifies about issues regarding the only changed lines in this file. In case of detected issues, this action will directly comment on the pull request under the precise line involved in the issue. Please note: this action is not blocking the merging, it is just a suggestion... I don't know if we want this action right now, but it could be a good idea IMHO, let me know what you think about it :)The
clang-format
andcmake-format
jobs will provide you a git-diff to resolve all the style issues in just one shotWhich issue(s) this PR fixes:
Fixes #381
Special notes for your reviewer:
Probably we want to preserve git history before applying the new style to all the code, this is why the pull request is still in
[WIP]
status. We have to decide how to proceed here.Does this PR introduce a user-facing change?: