Investigate how to support specifying `clang-format` minor and patch versions

[jidicula]

We found in #198 and llvm/llvm-project#93034 that LLVM occasionally introduces breaking changes in clang-format in patch (and presumably minor) version releases. Because this action just uses the latest version of clang-format under a major version, this action's output can be non-deterministic as minor and patch versions are accepted into Ubuntu and those changes are pulled into this repo's container image builds.

To reduce the effects of this thrashing, there are a couple of possible solutions:

1. Provide a way to specify minor and patch versions as args to the action. If these versions are added to the container images, this could be tricky as it expands the build matrix by a lot.
2. Check if the desired clang-format version is already in the PATH in the runner, and if it is, use that instead of the Docker image. This shifts the responsibility onto users of this action to get the appropriate LLVM tools into their Actions runners, which they're probably already doing for other CI workflows.

Requirements:

• implementation must not drop support for clang-format versions that this Action already supports. At this time, the earliest version I support is clang-format-3.9
• implementation should not introduce a new code path for some clang-format versions

Approaches tried and rejected (follow links for reasoning):

• pip builds: Install via pip instead of apt #264 (comment)

[ptsouchlos]

Option 2 IMO is probably going to be the most flexible. LLVM provides a script that can be downloaded via wget that's pretty easy to set up in a CI and then you can install whatever version of clang you want (almost). This is probably going to be the least maintenance work as well as updating for each minor patch release will probably be a pain.

[hannojg]

I just ran into that problem as well and agree that (2) would be a good option here!

[dkaszews]

I already specify the exact version of clang-format in my requirements.txt to avoid those breaking-patch issues, so would say most elegant way would be to support clang-format-version: local or use-clang-version-in-path: true.

[dkaszews]

I created a draft with alternative fix to specify minor version via pip, need some help with Docker.

[ptsouchlos]

A different approach that we took is to use the llvm.sh from LLVM directly to ensure we can always have the latest versions of the tools available in our CIs. This works decently well as long as we can keep our local tooling up to date.

[jidicula]

A different approach that we took is to use the llvm.sh from LLVM directly to ensure we can always have the latest versions of the tools available in our CIs. This works decently well as long as we can keep our local tooling up to date.

@DeveloperPaul123 could you elaborate on this? Would this work for all versions of LLVM that this project supports? Note that this Action supports clang-format-3.9 at the earliest.

[ptsouchlos]

A different approach that we took is to use the llvm.sh from LLVM directly to ensure we can always have the latest versions of the tools available in our CIs. This works decently well as long as we can keep our local tooling up to date.

@DeveloperPaul123 could you elaborate on this? Would this work for all versions of LLVM that this project supports? Note that this Action supports clang-format-3.9 at the earliest.

I don't think it covers all versions, but we just use it for versions > 19 since the main concern was getting the latest available version as soon as possible after it is released. This was my approach: xstrahl@9555f9f

We're not really concerned with supporting older versions of clang-format at my company, but if you're interested in this approach, I can upstream the above commit as a PR.