Closed 2bndy5 closed 2 years ago
Thanks for the link to the actual repo/workflow, that is most helpful! With that said, your extensive CMake presets are a bit difficult to follow for such a simple test.
There may be a problem with docker file system not seeing fmt/format.h in the runner's file system.
If you need to use a custom env (typically for non-std libs or cross-compiling), then I'd recommend trying the windows example workflow in the readme. You don't need to use windows, you just need to understand how to use this action's source as a python installable package. I put together an example based on the snippet you posted in the OP:
on:
pull_request:
types: [opened, reopened] # let PR-synchronize events be handled by push events
push:
jobs:
cpp-linter:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v3
- name: Install clang-tools
uses: KyleMayes/install-llvm-action@v1
with:
version: 14
# specifying an install path is not required for ubuntu
# directory: ${{ runner.temp }}/llvm
- name: Install linter python package
run: python3 -m pip install git+https://github.com/cpp-linter/cpp-linter-action@v1
- name: run linter as a python package
id: linter
run: cpp-linter --version=14 --style=file --tidy-checks='' --database=build/ci-linux-clang
- name: Fail fast?!
if: steps.linter.outputs.checks-failed > 0
run: echo "Some files failed the linting checks!"
# for actual deployment
# run: exit 1
BTW, that conan pkg mgr is a cool tool. Thanks for the lead on that!
@ibis-hdl Don't forget the step that installs LLVM:
- name: Install clang-tools
uses: KyleMayes/install-llvm-action@v1
with:
version: 14
This is important because you're not using the docker container for this action since you changed to using this action's python source code on the runner file system.
@ibis-hdl Don't forget the step that installs LLVM:
- name: Install clang-tools uses: KyleMayes/install-llvm-action@v1 with: version: 14
This is important because you're not using the docker container for this action since you changed to using this action's python source code on the runner file system.
Thanks, even I use Ubuntu-22.04 which has bundled clang-14 (and which seems to work)??
jobs:
cpp-linter:
runs-on: ubuntu-22.04
steps:
- name: Install basic dependencies
run: |
sudo apt-get update
sudo apt-get install --no-install-recommends -y cmake ninja-build ccache clang-14 clang-format clang-tidy
Anyway, I've changed the action to use the installable package a121d28 and run into same issue:
Run cpp-linter --version=14 --style=file --tidy-checks='' --ignore=build --database=build/ci-linux-clang
cpp-linter --version=14 --style=file --tidy-checks='' --ignore=build --database=build/ci-linux-clang
shell: /usr/bin/bash -e {0}
env:
CONAN_V2_MODE: 1
INFO:CPP Linter:Ignoring the following paths/files:
./build
INFO:CPP Linter:processing push event
Event json from the runner
Get list of specified source files
DEBUG:CPP Linter:Crawling "./"
DEBUG:CPP Linter:Crawling "./scripts"
DEBUG:CPP Linter:Crawling "./build"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/bin"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/CMakeFiles"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/CMakeFiles/3.23.2"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/CMakeFiles/3.23.2/CompilerIdCXX"
DEBUG:CPP Linter:"./build/ci-linux-clang/CMakeFiles/3.23.2/CompilerIdCXX/CMakeCXXCompilerId.cpp" is a source code file
DEBUG:CPP Linter:"./build/ci-linux-clang/CMakeFiles/3.23.2/CompilerIdCXX/CMakeCXXCompilerId.cpp" is ignored as specified in the domain "./build"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/CMakeFiles/3.23.2/CompilerIdCXX/tmp"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/CMakeFiles/CMakeTmp"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/source"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/source/CMakeFiles"
DEBUG:CPP Linter:Crawling "./build/ci-linux-clang/source/CMakeFiles/github-action.dir"
DEBUG:CPP Linter:Crawling "./source"
DEBUG:CPP Linter:"./source/main.cpp" is a source code file
INFO:CPP Linter:Giving attention to the following files:
source/main.cpp
Performing checkup on source/main.cpp
INFO:CPP Linter:Running "clang-tidy-14 --export-fixes=clang_tidy_output.yml -p /home/runner/work/gh-actions-test/build/ci-linux-clang source/main.cpp"
DEBUG:CPP Linter:Output from clang-tidy:
/home/runner/work/gh-actions-test/gh-actions-test/source/main.cpp:4:10: error: 'fmt/format.h' file not found [clang-diagnostic-error]
#include <fmt/format.h>
^~~~~~~~~~~~~~
....
I'm also confused about Linter:Ignoring the following paths/files: ./build
and than Linter:Crawling "./build ..."
Oh I didn't see that step in your workflow (hidden in the diff).
I'm also confused about
Linter:Ignoring the following paths/files: ./build
and thanLinter:Crawling "./build ..."
Anyway, I've changed the action to use the installable package a121d28 and run into same issue:
Believe it or not I think we're getting closer to solving this. Now that you've got the action running in your runner's File system, it is just a matter of making sure clang-tidy knows where to look for fmt/format.h
. So, here's where I have to ask some very project specific questions (thankfully your project is a test bed).
fmt/format.h
?fmt
in your compilation database (generated by cmake)?Believe it or not I think we're getting closer to solving this. Now that you've got the action running in your runner's File system, it is just a matter of making sure clang-tidy knows where to look for
fmt/format.h
. So, here's where I have to ask some very project specific questions (thankfully your project is a test bed).
Where is conan putting
fmt/format.h
?Is the path to
fmt
in your compilation database (generated by cmake)?
Conan builds the binaries and installs them into an own directory, e.g. on Linux
$ conan info . --paths
...
export_folder: /home/vscode/.conan/data/fmt/8.1.1/_/_/export
source_folder: /home/vscode/.conan/data/fmt/8.1.1/_/_/source
build_folder: /home/vscode/.conan/data/fmt/8.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6
package_folder: /home/vscode/.conan/data/fmt/8.1.1/_/_/package/2c09c8f84c016041549fcee94e4caae5d89424b6
...
using conan.cmake one is able to use the generated CMake Find... (concrete Findfmt.cmake
here) commands to build the project as usual by setting project's
target_include_directories(${PROJECT_NAME}
PUBLIC
$<INSTALL_INTERFACE:include>
PRIVATE
$<BUILD_INTERFACE:${fmt_INCLUDE_DIR}>
)
which explains, why the CMake's generated compile_commands.json
is required for Clangs's tooling - and here we are :)
compile_commands.json:
[
{
"directory": "/workspaces/gh-actions-test/build/ci-linux-clang",
"command": "/usr/bin/clang++ -I/workspaces/gh-actions-test/source -isystem /home/vscode/.conan/data/fmt/8.1.1/_/_/package/4539af7a6a16a6e8e29b0d4718fe4601b7500274/include -O3 -DNDEBUG -std=c++20 -o source/CMakeFiles/github-action.dir/main.cpp.o -c /workspaces/gh-actions-test/source/main.cpp",
"file": "/workspaces/gh-actions-test/source/main.cpp"
}
]
It seems to me that this isn't found or even not used; otherwise it would find the include/lib directories.
I'm trying to build your project locally, but the CMake setup is so complex that I'm having trouble.
I did notice a rather slight difference between the example in the conan README and your project's target_include_directories()
call:
find_package(fmt CONFIG)
add_executable(main main.cpp)
target_link_libraries(main fmt::fmt)
whereas you're using
target_include_directories(${PROJECT_NAME}
PUBLIC
$<INSTALL_INTERFACE:include>
PRIVATE
$<BUILD_INTERFACE:${fmt_INCLUDE_DIR}>
)
I don't really use CMake's generator statements, so I don't know what $<BUILD_INTERFACE:${fmt_INCLUDE_DIR}>
resolves to.
I need to see exactly where conan is putting fmt
lib (your answer wasn't very clear about that - IDK how to use/understand conan cmds).
ok I finally got cmake to generate successfully, and I ran clang-tidy without complaints. There must be something else going on with the CI runner... Still trying to figure this one out.
These are the cmds I ended up using:
source env/bin/activate
pip install conan cmake
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
clang-tidy ../source/main.cpp -p .
I'm trying to build your project locally, but the CMake setup is so complex that I'm having trouble.
thanks you for investigating.
I did notice a rather slight difference between the example in the conan README and your project's
target_include_directories()
call:find_package(fmt CONFIG) add_executable(main main.cpp) target_link_libraries(main fmt::fmt)
whereas you're using
target_include_directories(${PROJECT_NAME} PUBLIC $<INSTALL_INTERFACE:include> PRIVATE $<BUILD_INTERFACE:${fmt_INCLUDE_DIR}> )
I don't really use CMake's generator statements, so I don't know what
$<BUILD_INTERFACE:${fmt_INCLUDE_DIR}>
resolves to.
You are right, the $<BUILD_INTERFACE:${fmt_INCLUDE_DIR}>
isn't required (just tested); IIRC CMake's alias fmt::fmt does the job.
I need to see exactly where conan is putting
fmt
lib (your answer wasn't very clear about that - IDK how to use/understand conan cmds).
are you looking for
conan profile new --detect --force default
# enforce new CXX11 ABI for gcc/clang
conan profile update settings.compiler.libcxx=libstdc++11 default
conan install . --remote conancenter --build missing --profile default
$ conan profile show default
...
$ conan info . --paths
...
Same procedure on Windows, but (my) paths are different (since I set explicit conan's storage path to D:\.conan); default is %USERPROFILE%\.conan
on Windows, ~/.conan
on Linux, where .../.conan/data
is the package storage.
❯ conan info . --paths
...
export_folder: D:\.conan\data\fmt\8.1.1\_\_\export
source_folder: D:\.conan\data\fmt\8.1.1\_\_\source
build_folder: D:\.conan\data\fmt\8.1.1\_\_\build\b4e2bc17a9dd604e8c03a12fd8642f5b9fbb34d5
package_folder: D:\.conan\data\fmt\8.1.1\_\_\package\b4e2bc17a9dd604e8c03a12fd8642f5b9fbb34d5
...
I agree, my CMakePresets.json
is oversized for this test, but this is from my (to publish) project (also .clang-{format,tidy}). You can, e.g.
$ cmake --list-presets=all
...
$ cmake --preset windows-msvc-release
...
$ cmake --build --preset windows-msvc-release --target clean
...
$ cmake --build --preset windows-msvc-release
...
$ ctest --preset windows-msvc-release
...
Hope this helps!
BTW; cmake > 3.20 is required due to use of CMake's presets.
I suspect there's a limit to what clang-tidy can access on the CI runner's FS. I'll have to continue with this tomorrow (its getting late here). I intend on delving into the GH actions docs to see about runner's FS access.
I suspect the home folder isn't a good place for install. Does the runner successfully compile the project?
3.20 is required due to use of CMake's presets.
Yeah I ran into that also.
I'm working from WSL (Ubuntu bash for Windows) because I appreciate having an isolated env for testing other's projects.
Does the runner successfully compile the project?
yes, here on Windows
> git clone https://github.com/ibis-hdl/gh-actions-test.git
...
> cd .\gh-actions-test\
> python -m venv .venv
> .\.venv\Scripts\activate
> pip --disable-pip-version-check --no-cache-dir install wheel conan git+https://github.com/cpp-linter/cpp-linter-action@v1
...
> cmake --preset windows-msvc-release
Preset CMake variables:
CMAKE_BUILD_TYPE="Release"
CMAKE_CXX_COMPILER="cl"
CMAKE_EXPORT_COMPILE_COMMANDS="ON"
CMAKE_INSTALL_PREFIX="D:/My/IBIS/cpp-lint/gh-actions-test/build/windows-msvc-release/install"
-- The CXX compiler identification is MSVC 19.32.31329.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.32.31326/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python3: D:/My/IBIS/cpp-lint/gh-actions-test/.venv/Scripts/python.exe (found version "3.10.4") found components: Interpreter
-- Downloading conan.cmake from https://github.com/conan-io/cmake-conan
-- Conan: Detected VS runtime: MD
-- Conan: checking conan executable
-- Conan: Found program D:/My/IBIS/cpp-lint/gh-actions-test/.venv/Scripts/conan.exe
-- Conan: Version found WARN: Migration: Updating settings.yml
...
Conan version 1.49.0
-- Conan executing: D:/My/IBIS/cpp-lint/gh-actions-test/.venv/Scripts/conan.exe install D:/My/IBIS/cpp-lint/gh-actions-test --remote conancenter --build missing --settings arch=x86_64 --settings build_type=Release --settings compiler=Visual Studio --settings compiler.version=17 --settings compiler.runtime=MD --settings compiler.cppstd=20
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=20
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
conanfile.txt: Installing package
Requirements
fmt/8.1.1 from 'conancenter' - Cache
Packages
fmt/8.1.1:90f2cd62afd916ec8c67e719700220ea58131a86 - Cache
Installing (downloading, building) binaries...
fmt/8.1.1: Already installed!
conanfile.txt: Generator txt created conanbuildinfo.txt
conanfile.txt: Generator cmake_find_package created Findfmt.cmake
conanfile.txt: Aggregating env generators
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo
-- Conan: Using autogenerated Findfmt.cmake
-- Found fmt: 8.1.1 (found suitable version "8.1.1", minimum required is "8.1.1")
-- Library fmt found D:/.conan/data/fmt/8.1.1/_/_/package/90f2cd62afd916ec8c67e719700220ea58131a86/lib/fmt.lib
-- Found: D:/.conan/data/fmt/8.1.1/_/_/package/90f2cd62afd916ec8c67e719700220ea58131a86/lib/fmt.lib
-- Configuring done
-- Generating done
-- Build files have been written to: D:/My/IBIS/cpp-lint/gh-actions-test/build/windows-msvc-release
> cmake --build --preset windows-msvc-release
[2/2] Linking CXX executable bin\github-action.exe
> ctest --preset windows-msvc-release
Test project D:/My/IBIS/cpp-lint/gh-actions-test/build/windows-msvc-release
Start 1: github-action-main
1/1 Test #1: github-action-main ............... Passed 0.02 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.03 sec
and runs also as CMake build #62 which is the 'base' for my cpp-linter.yml
action.
I'm working from WSL (Ubuntu bash for Windows) because I appreciate having an isolated env for testing other's projects.
understandable :)
Actually I can't use WSL here since WSL haven't internet connection (my admin doesn't know why) and hence I can't install anything there, but later on I can do it at another Windows box (or even I start my Fedora dual-boot).
BTW, WSL(2) with Ubuntu 22.04 is required. Then the bundled tools are sufficient, no ppa etc.
Pretty sure my WSL Ubuntu is still on 20.04, and I just had to update CMake to make it work.
Are any further formations required; shall I still run it on Linux box? I would expect the same behavior.
Sorry, I completely forgot about this. I don't have anything new for you. It wouldn't hurt to try in on a Linux runner (if it works then, it would help narrow things down).
The thing that alludes me is that it works on a local machine, but not on the workflow runner's VM. The Compilation database from CMake is using absolute paths, so there shouldn't be a difference in locating the external lib.
I ran into the same problem and found the cause: The prepended base path is incorrectly computed. As you can see in my attempts to integrate this, the checkout action clones the repository concrete
to [1]
/home/runner/work/concrete/concrete
However, given --database=build/x64-linux-clang
this action computes the absolute path as [2]
-p /home/runner/work/concrete/build/x64-linux-clang
while it should be
/home/runner/work/concrete/concrete/build/x64-linux-clang
I worked around this by using --database=concrete/build/x64-linux-clang
for now which works fine.
Thanks for reporting this fix. Just my luck that it turned out to be something simple...
Not sure how or if there should be a alteration to the code since build paths can be wildly different per project. Once I confirm this, I'll probably update the readme with an example usage of the -p
option.
Why prepend a base path at all and not just pass it to clang-tidy
as specified? That would be less surprising since all other paths are relative to the current working directory as well (e.g. ignore
).
IIRC, the prepended path was to keep compatibility with using the docker image (which uses a sequestered File System).
If we remove the prepended path, then it would be even more confusing for people using the docker image.
@BurningEnlightenment Please direct you queries about prepending the database to #73 . I'm not dismissing the idea, but it needs a separate thread.
I just found out there's another bug in the code that hides the warning from clang-tidy when it can't find the database (and uses "default flags").
https://github.com/cpp-linter/cpp-linter-action/blob/d24e6225d827632732599cb812817ac086781cfd/cpp_linter/run.py#L443-L444 To reveal this warning in a consistent manner, the above snippet should be
if results.stderr:
logger.warning(
This might be solved with the latest changes to the main branch. All relative paths given to the database option are made absolute. However, the database option seems broken when using the docker env -- using as a python pkg is preferred for the database path to be correctly accessed.
I see. Thanks for answer. Thanks for this action and your time to support!
Meanwhile, I run into another issue with regard to clang tidy's database (I'm not sure to open another issue - it's at yours). My action looks like
where
CMakePresets.json
containsThe action's log shows that it fails:
Otherwise, running VS Code's devcontainer shows relative path seems to work:
I haven't the experience with clang-tidy using CLI arguments and python, so my guess is that's there is a wrong path (otherwise not very likely) :(
If relevant, the action is here
Originally posted by @ibis-hdl in https://github.com/cpp-linter/cpp-linter-action/issues/64#issuecomment-1154250055