Best way to track .clang-tidy files?

[SGauvin]

Hello, I started using the prelude's clang-tidy integration (see e7b86c8 and 393e26c) (thanks @skrueger).

I'm wondering if there's a provisioned way to be able to track the .clang-tidy files? Right now if I have target that lints correctly, and I make a change to my .clang-tidy file that would make said target fail, re-running [check-all] on that target just uses the cached successful result.

My understanding here of the issue is that the clang-tidy config that is resolved is not part of the inputs of the clang-tidy rule. Some ways that I can think this could work:

1. Automatically find all the .clang-tidy files that could affect a given target by walking up the directories until the repo's root (because a .clang-tidy file can have InheritParentConfig: true, and have these as inputs to the clang-tidy rule.
2. Have the prelude/cxx/tools/clang_tidy_wrapper.py script take a --config-file=, which it would then give to the clang-tidy process it spawns. Not sure if that's possible, but we could maybe make use of the --dump-config clang-tidy flag to let it resolve the actual config of a given directory (it would walk up the directories and resolve the final real config as a single file).
3. Use --config= in clang tidy and stop relying on a clang-tidy file. The issue with that now is that your local .clang-tidy files can go out of sync with what you're doing your CI linting with, which would then be bad for DX (clangd wouldn't know what the CI checks are).

Not sure if any of those ideas are good (I don't like number 3)? Right now the only way that I know to actually make sure your repo is clang-tidy compliant after a .clang-tidy change is to buck2 clean the repo.

[cbarrete]

I'm wondering the same thing, and in particular how Meta deals with this.

AFAIK 1 is not possible with a regular rule (including the [check-all] subtarget) because of visibility rules. It's possible to walk parent directories in BXL though.

2 would require a way to have fine grained control over what actions run locally vs remotely. If it is possible, I'd be very interested in learning how to do it.

[skrueger]

I'm investigating how to handle this. This appears to be a bug in the current implementation. Thank you for reporting it.

I want to briefly respond to let you know this has my attention, but unfortunately I do not have a solution yet. Ideally, I'd like to do approach 1 but (as @cbarrete points out) that may not be possible because of access restrictions.

2 would require a way to have fine grained control over what actions run locally vs remotely. If it is possible, I'd be very interested in learning how to do it.

I know an action will run locally when local_only = True is passed to AnalysisActions#run.
https://buck2.build/docs/api/build/AnalysisActions/#analysisactionsrun

[cbarrete]

I know an action will run locally when local_only = True is passed to AnalysisActions#run.

Indeed, but it doesn't propagate to anything that you depend on (which is sometimes desirable, sometimes painful). I can get into details if it's helpful, but it may not be relevant here, I might just be projecting the issues I have with my clang-tidy integration, which requires running with --local-only.