-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
ci: run clang-tidy as a part of CI #4666
Conversation
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
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.
Very nice!
.clang-tidy
Outdated
@@ -0,0 +1,306 @@ | |||
--- | |||
# -cppcoreguidelines-pro-type-vararg: It will alert on every ASSERT. |
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.
Can you add some more comments about how this file was generated / where it comes from?
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.
Done
@lizan did you mean to push a change? |
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
.clang-tidy
Outdated
@@ -0,0 +1,315 @@ | |||
--- | |||
# This file defines what clang-tidy checks and parameter. It is experimental, and may let |
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.
@envoyproxy/maintainers I am open to any suggestion to this file. With this .clang-tidy
it still issue too many warnings. A result from a couple days ago:
https://gist.github.com/lizan/115f05ace9ac7dbae4c042f6fbdb3596
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.
Hmm. Don't we need to fail if clang-tidy fails? So don't we need to be warning clean? Or we only fail on errors? In general it seems like we should be warning clean also.
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.
No I don't think we should mark clang-tidy required, at least in a meanwhile. We can make some of checks error with -warnings-as-errors
later to fail on them.
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.
Then what's the point of using a CI slot for this? No one will look at it.
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.
Just like mac CI that is not required (on GitHub) but we still check? At this point, there are too many warnings to fix at once so I am hesitating to make them error.
cc @jsedgwick @rlazarus @PiotrSikora on #921, any suggestion to enable some checks as WarningsAsErrors
?
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.
How does Google deal with this internally? Since Google fixes bugs raised by clang-tidy presumably some internal CI is catching them? Can we just start with Google's config? cc @htuch @alyssawilk @PiotrSikora
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.
Internally clang-tidy is largely advisory I believe, but most reviewers will take its suggestions as actionable. For Envoy, only some importers (we have a weekly rotation) actually pay attention as it's largely mechanical.
I think we have a noise problem with a purely advisory clang-tidy, if the report is as noisy as in https://gist.github.com/lizan/115f05ace9ac7dbae4c042f6fbdb3596, reviewers will never both to look at it. Inside Google, our review system highlights issues only in the delta diff.
Maybe we can turn off all warnings, make clang-tidy compulsory and only turns on the ones that actually are low on the false positive side?
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 running clang-tidy on diff (especially for PRs) is definitely the plan, considering how clang-tidy is heavy (it takes an hour to run on whole source code). There is a tool to run clang-tidy against diff.
If we do have a better .clang-tidy to start with, I'm happy to start with that rather than 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.
+1, IMO we need to make this actionable or we shouldn't bother running it in CI.
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
re: #4666 (comment) @mattklein123 OK Now I cleaned up The remaining warning checks are also valid, but hard to fix in short time. I'll explore if diff check will make more sense for those Here is the latest result: https://gist.github.com/lizan/23b289b977e4d85c140d61b187a08e03 If we agree on errors checks, we need a single sweep to all source to fix existing errors in another PR. cc @envoyproxy/maintainers |
Can we ignore warnings in thirdparty code? In general yes these warnings seem reasonable to me. Can we do diffs and then turn it on as failing? Then we can potentially have someone go through and clean up the existing code as a background exercise. |
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
The default header filter already filtered out many of them, but some of them are still raised regardless what I specify for header filter, I guess some of them are in macro expansion etc. The compilation database doesn't contain third party cc files so they are not checked at all. Added |
#4835 addressed the CI failure, @mattklein123 PTAL again. |
@lizan I don't see clang-tidy running in the checks. Will it only run when merged to master? I thought it should run as part of this PR? |
ci/build_setup.sh
Outdated
ln -sf "${ENVOY_SRCDIR}"/.bazelrc "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/ | ||
ln -sf "${ENVOY_SRCDIR}"/.bazelrc "${ENVOY_CI_DIR}"/ | ||
cp "${ENVOY_SRCDIR}"/.bazelrc "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/ | ||
cp "${ENVOY_SRCDIR}"/.bazelrc "${ENVOY_CI_DIR}"/ |
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.
What's the reason for this change? It leads to an error and early termination of CI step for me:
$ ENVOY_DOCKER_BUILD_DIR=~/build ./ci/run_envoy_docker.sh './ci/do_circle_ci.sh bazel.clang_tidy'
disk space at beginning of build:
Filesystem Size Used Avail Use% Mounted on
overlay 504G 322G 163G 67% /
tmpfs 64M 0 64M 0% /dev
tmpfs 97G 0 97G 0% /sys/fs/cgroup
/dev/sda1 504G 322G 163G 67% /build
shm 64M 0 64M 0% /dev/shm
tmpfs 97G 0 97G 0% /proc/acpi
tmpfs 97G 0 97G 0% /sys/firmware
No remote cache bucket is set, skipping setup remote cache.
ENVOY_SRCDIR=/source
HEAD is now at 3e5b733... cleanup: match NOT_IMPLEMENTED_GCOVR_EXCL_LINE change (#53)
cp: '/source/.bazelrc' and '/source/ci/.bazelrc' are the same file
disk space at end of build:
Filesystem Size Used Avail Use% Mounted on
overlay 504G 322G 163G 67% /
tmpfs 64M 0 64M 0% /dev
tmpfs 97G 0 97G 0% /sys/fs/cgroup
/dev/sda1 504G 322G 163G 67% /build
shm 64M 0 64M 0% /dev/shm
tmpfs 97G 0 97G 0% /proc/acpi
tmpfs 97G 0 97G 0% /sys/firmware
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.
the bazel-compile-database doesn't read bazel options from env variable so the script dumps to bazelrc. this keeps git clean without writing to original file.
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
@lizan can you introduce a temporary clang-tidy failure into this PR (that we can then revert) just so we can see what the CI output/failure looks like? |
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
@lizan nice this is awesome. If you revert the test commit this LGTM! |
This reverts commit 6904c85. Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Using cp results in: cp: '/source/.bazelrc' and '/build/envoy-filter-example/.bazelrc' are the same file *Risk Level*: Low *Testing*: ./ci/run_envoy_docker.sh './ci/do_circle_ci.sh bazel.dev' *Docs Changes*: n/a *Release Notes*: n/a Broken in envoyproxy#4666. Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Using cp results in: cp: '/source/.bazelrc' and '/build/envoy-filter-example/.bazelrc' are the same file *Risk Level*: Low *Testing*: ./ci/run_envoy_docker.sh './ci/do_circle_ci.sh bazel.dev' *Docs Changes*: n/a *Release Notes*: n/a Broken in #4666. Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Using cp results in: cp: '/source/.bazelrc' and '/build/envoy-filter-example/.bazelrc' are the same file *Risk Level*: Low *Testing*: ./ci/run_envoy_docker.sh './ci/do_circle_ci.sh bazel.dev' *Docs Changes*: n/a *Release Notes*: n/a Broken in envoyproxy#4666. Signed-off-by: Piotr Sikora <piotrsikora@google.com> Signed-off-by: Fred Douglas <fredlas@google.com>
Signed-off-by: Lizan Zhou lizan@tetrate.io
Description:
Run clang-tidy as a part of CI.
Risk Level: Low
Testing: CI, manual
Docs Changes: N/A
Release Notes: N/A
Fixes #921.