-
Notifications
You must be signed in to change notification settings - Fork 21
Why prepend a path to database? #73
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
Comments
Moved this question to a new thread because it could be a new feature if we work it right. |
Note to self: This feature would be considered a breaking change (major version bump). |
I just had a look at your sources; is there a specific reason for using cpp-linter-action/cpp_linter/run.py Line 42 in d24e622
cpp-linter-action/cpp_linter/run.py Lines 423 to 424 in d24e622
According to the github actions documentation GITHUB_WORKSPACE points to the default checkout path. While I find no mention of RUNNER_WORKSPACE it seems to always be pointing to the wrong directory in this case.
|
Because the runner workspace is different from the docker's workspace. |
@shenxianpeng It might be easier to identify when using the docker at runtime if the docker image set a environment variable. We could probably do this from the action.yml in this repo, but it might be good to have in the docker container. If we could more easily identify when the docker is in use (at runtime), then we can make this path prepending conditional on the presence of the docker workspace. |
A mostly backward compatible option could be to only prepend a path if database isn't an absolute path. In which case I could simply do |
I like where your head is at! If you're comfortable with python, you could submit a PR with that idea. Otherwise, it may take me a while to carve out some time to test/implement it myself. |
@2bndy5 OK, we can set an environment variable to the docker image to identify it is running. |
A new docker image Status: Downloaded newer image for xianpengshen/clang-tools:all
root@bb3520f7c535:/src# echo $CLANG_VERSIONS
14 13 |
I'm starting to think that making the given database path absolute is required for compatibility with all versions of clang-tidy... I'm getting inconsistent results in the unit test.
|
Turns out The unit tests are passing now, but I have to make sure this doesn't break compatibility with the docker env (unit tests are not using the docker env). |
@shenxianpeng I don't think the new env var from the docker image can be accessed from the github runner. I'm setting a custom env var from actions.yml instead. It looks like the database option wasn't working before... See #65 (comment) for context. The action wasn't showing any problems when clang-tidy exited with 0. But now I have the action displaying any stderr output (despite the return code), and the Tested with docker envWith
|
I think part of the problem is that everything the user does in a github workflow is executed with sudo permission. Maybe the programs in the docker doesn't have the same root user permission. So, when we create a build dir and generate a database from other steps in the workflow, this action's docker-contained clang-tidy may not be able to freely browse the build dir (owned by the user |
About Docker container filesystem. and we don't set |
ok I think the
where the @BurningEnlightenment This might also mean that if a user passes an absolute path like |
I think there's something else going on (probably a symlink resolution).
So, now I'm passing the right path to the database ( I'm not sure we can even support the |
Using relative only paths to a db didn't work. Clang-tidy still looked for the db using an absolute path in the runner's context. Reverting that attempt/commit since it's better to use absolute paths when possible. |
Maybe if we copy the db file to the This would open us up to other problems like naming scheme for various generated db files; most use the filename compile_commands.json, but clang tools also support a generic "compile_flags.txt" (which must use relative paths within). I suppose we could detect if the db path is a dir or a file too. |
Well, this issue is mostly solved for users running this action as a python package. The database option may have to remain broken for users using the docker image. I'd temporarily encourage users to copy the database over to the root source directory of the repo being linted. We can probably change this action into a composite action (a series of |
So, I modified the test repo's CI to do - name: generate database
run: cmake -Bbuild src -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
- name: Move database into src folder for implicit clang-tidy discovery
run: mv build/compile_commands.json src/
- name: Run cpp-linter as action (not python pkg)
uses: cpp-linter/cpp-linter-actioin@backlogged-updates
with:
ignore: build # does not affect clang-tidy directly (& not supposed to)
version: 12
file-annotations: true Unfortunately, clang-tidy finds the build folder and tries to traverse it anyway.
This error prevents clang-tidy from doing any further analysis, meaning there are no file annotations. Running the action as python pkg seems to have no problems converting a relative database path into an absolute path. Everything is working as expected there. So, I think the only real way to fully support a generated database, is to convert the action into a composite action (which removes the use of the docker env). |
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
).Originally posted by @BurningEnlightenment in #65 (comment)
The text was updated successfully, but these errors were encountered: