we see the analysis for the main branch, but PR and its branch does not show any issue, even though it should.
The analysis and PR decoration was working for us some time ago, but due to other issues we had I am not able to give more precise estimation than ‘half a year ago’.
Since then we altered the way we build the project, and I am aware that SonarCloud has also introduced number of changes.
I think that the problem might be the way we build the project.
Our software consist of several repositories. During build on Travis, we move/copy (using python’s copy/move functions) content of the current repo into another folder (./src/xmipp). We copy the .git folder (otherwise SonarCloud wasn’t able to match analysis with respective PR). The whole script is available here.
This naturally results in git reporting (correctly) many missing files in the root folder, and no changes in the ‘src/xmipp’.
Then the build script (among others) clones other repositories to the ‘src’ folder, performs the compilation (the project is mostly C++) using the wrapper and then runs the scanner.
no, it is a moved file. As I said in the first post, our project consist of several repositories, and we need to do some files shuffling prior the build.
Then it explain why it doesn’t work. We are using scm diff between branches to identify changed files/lines in a PR. But in the end you are analyzing the src folder that is not commited in the repo, so it will fail to identify those files as part of the PR.
I see.
How exactly is the comparison done?
Will it help e.g. to move the files using git mv instead of the python’s move?
If I set the ‘xmipp’ folder as a root one here, will it change something?
What other options do we have?
If you try using git mv, the file will be detected as uncommited by git, and I think we are excluding such files from the analysis. And if you try to commit them before the analysis, I’m also afraid of possible side effects. @dmeneses or @janos any idea?
Committing the files should be OK, I don’t expect any side effects.
I also suspect that git mv won’t be enough. IIRC we compare HEAD with the fork point, so it’s not enough to stage the changes. In any case you can try it.
Can I somehow set the root folder for the anlysis?
What I mean is:
in repo, we have ‘./libraries/’ folder with cpp files.
Then we move whole repo (including .git folder) to ‘./src/xmipp/’
The build script then enters the ‘/.src/xmipp/’ folder and compiles from there.
So, for the build wrapper, it seems that the ‘src/xmipp’ folder is the root.
If I can set the same for the analysis plugin, it should solve the problem, as the content of the ‘./src/xmipp’ did not change.
When I used git mv and git commit, the changes were detected, but the analysis did not match with the PR in git (marked as Queued).
I guess it is because of the commit sha not matching the one of the PR.
Probably, yes. We are working on a better way to detect the sha1 that should be decorated, using Travis env variable instead of looking at the Git repo. That should help in your case.
I have also tried to simply copy everything (i.e. keep a copy of ‘libraries/…’) in the root folder.
The PR was correcly matched with the analysis, but for some reason there were no indexed files.
I tried to change the include/exclude rules, but the log said that no cpp file has been processed. I guess that it might be cause by some inconsistencies between build-wrapper and the rules.
since 9th April we have no analysis even on the base branch.
Currently we are preparing for changing the repo structure, so that we don’t need to move the files.
shall we then consider this topic as closed while you change the structure?
I would recommend you to open a new thread once you have changed the structure, if the problem persist.