Fixes https://docs.docker.com/reference/build-checks/from-as-casing/ which also gives warning when building container from command line: ``` => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1) => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 4) => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 40) => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 100) ```
See the third version of the PR description for the changes that will be made.
Similar to #158335. pr-code-lint.yml was in progress as a PR when that change landed, so this workflow did not get updated.
This patch bumps the CI container version to the latest release version. No particular reason to do this other than to ensure that we are using a clang built with IRPGO now that has relanded for the slight performance benefit.
Add me to the document so that I will receive notifications in case there are any changes to DLTI infrastructure.
So that I will receive updates on changes to the Transform dialect.
These separate checkouts I believe were originally carried over from when we were using pull_request_target. We needed two checkouts to ensure we were not executing user supplied code. We kept them to ensure we were using the latest version of the tools, but this was born mostly out of a misunderstanding of how Github Actions works. All PRs directly against main are executed as if merged into main, so already are using the latest version of the tools no matter the branch point. Stacked PRs still need to be rebased for changes to propagate but these files have been pretty stable for the past two years or so and I can't imagine any changes needed to keep things running on release/stacked PR branches.
This patch ensures that the pr-code-lint workflow is run for testing whenever the workflow file is changed. This will not catch actual functionality issues on most changes but does ensure that the workflow is not completely broken.
**KEY POINTS** - MVP workflow to automatically lint C++ files, located **only** in `clang-tools-extra/clang-tidy`. It's chosen this way as `clang-tools-extra/clang-tidy` is almost 100% `clang-tidy` complaint, thus we would automatically enforce a [high quality standard for clang-tidy source code](https://discourse.llvm.org/t/rfc-create-hardened-clang-tidy-config-for-clang-tidy-directory/87247). (https://github.com/llvm/llvm-project/pull/147793) - Implementation is very similar to code-format job, but without the ability to run `code-lint-helper.py` locally. **FOUND ISSUES** + open questions - Speed: it takes ~ 1m40sec to download and unpack `clang-tidy` plus additional ~4 mins to configure and CodeGen targets. I see that `premerge.yaml` runs on special `llvm-premerge-linux-runners` runners which can use `sccache` for speed. Can we use the same runners for this job? Exact timings can be found [here](https://github.com/llvm/llvm-project/actions/runs/17135749067/job/48611150680?pr=154223). **TO DO** - Place common components from `code-lint-helper.py` and `code-format-helper.py` into a separate file and reuse it in both CI's. - Compute CodeGen targets based on `projects_to_build`, for now `clang-tablegen-targets` is hardcoded for `clang-tools-extra/`. - Automatically generate and upload `.yaml` for `clang-apply-replacements` - Create an RFC with a plan how to enable `clang-tidy` in other projects so that Maintainers of LLVM components could choose if they want `clang-tidy` or not. - Add more linters like `pylint`, `ruff` in the future.