Skip to content
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

Closed
wants to merge 15 commits into from

Conversation

Andreagit97
Copy link
Member

@Andreagit97 Andreagit97 commented Jul 11, 2022

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 the pre-commit framework, let me know if it looks good to you! 😄

  • You can find the configuration for clang-format and cmake-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 the tabsize to 4, this seems reasonable to me, but let me know about it)

  • I merged the old coding_conventions.md file into the new Contributing.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 and cmake-format jobs will provide you a git-diff to resolve all the style issues in just one shot

Which 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?:

NONE

* 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>
@poiana
Copy link
Contributor

poiana commented Jul 11, 2022

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@poiana poiana requested review from fntlnz and mstemm July 11, 2022 13:37
@Andreagit97
Copy link
Member Author

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 😄

Copy link
Contributor

@Molter73 Molter73 left a 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 @@
---
Copy link
Contributor

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!

.cmake-format.json Outdated Show resolved Hide resolved
- name: Install clang-tools 📥
uses: KyleMayes/install-llvm-action@v1.5.3
with:
version: 12.0.0
Copy link
Contributor

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?

Copy link
Member Author

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

.github/workflows/linting.yml Outdated Show resolved Hide resolved
@@ -0,0 +1,80 @@
#
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Member Author

@Andreagit97 Andreagit97 Jul 11, 2022

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 🤔

Copy link
Member Author

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?

Signed-off-by: Andrea Terzolo andrea.terzolo@polito.it

Co-authored-by: Mauro Ezequiel Moltrasio <moltrasiom@hotmail.com>
@deepskyblue86
Copy link
Contributor

@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.

@poiana
Copy link
Contributor

poiana commented Sep 5, 2023

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

@Andreagit97
Copy link
Member Author

/remove-lifecycle stale

@poiana
Copy link
Contributor

poiana commented Dec 5, 2023

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

@Andreagit97
Copy link
Member Author

/remove-lifecycle stale

@poiana
Copy link
Contributor

poiana commented Mar 4, 2024

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

@incertum
Copy link
Contributor

incertum commented Mar 4, 2024

/remove-lifecycle stale

@poiana
Copy link
Contributor

poiana commented Jun 2, 2024

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

@Andreagit97
Copy link
Member Author

/remove-lifecycle stale

@leogr
Copy link
Member

leogr commented Jun 4, 2024

I would like to bring this up again

@Andreagit97 Andreagit97 modified the milestones: TBD, 0.18.0 Aug 22, 2024
@Andreagit97
Copy link
Member Author

if we all agree I would move this to 0.18.0

/milestone 0.18.0

@FedeDP
Copy link
Contributor

FedeDP commented Aug 22, 2024

I agree! We wait a bit long for this one to land 😄

Signed-off-by: Andrea Terzolo <andreaterzolo3@gmail.com>
@poiana
Copy link
Contributor

poiana commented Aug 27, 2024

Adding label do-not-merge/contains-merge-commits because PR contains merge commits, which are not allowed in this repository.
Use git rebase to reapply your commits on top of the target branch. Detailed instructions for doing so can be found here.

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.

Copy link

Perf diff from master - unit tests

     2.76%     +1.39%  [.] gzfile_read
     3.47%     +1.38%  [.] sinsp_evt::load_params
     5.76%     -1.16%  [.] sinsp_evt::get_type
     2.05%     +0.99%  [.] sinsp_thread_manager::find_thread
     4.48%     -0.83%  [.] sinsp_parser::process_event
     5.93%     -0.67%  [.] next
     7.10%     -0.63%  [.] sinsp::next
     2.10%     -0.53%  [.] sinsp::fetch_next_event
     0.22%     +0.50%  [.] sinsp_fdtable::find
     1.75%     +0.49%  [.] std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release

Heap diff from master - unit tests

peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Heap diff from master - scap file

peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Copy link

codecov bot commented Aug 27, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.20%. Comparing base (eb374bc) to head (135cc56).
Report is 29 commits behind head on master.

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     
Flag Coverage Δ
libsinsp 74.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@leogr
Copy link
Member

leogr commented Aug 28, 2024

if we all agree I would move this to 0.18.0

/milestone 0.18.0

🥳

@Andreagit97
Copy link
Member Author

closed in favor of #2038

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Coding style for libs repo
7 participants