It does look like we’ve never managed to get caching working properly for PR analysis, but that’s a 2nd issue. I’d like to know if there’s anything else we can look at to try and improve the analysis times.
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
Apologies, the debug output for the analysis task is exceptionally large. Would it be possible to send you the output directly? Mainly as I’m not sure which bits are needed or not and don’t want to sanitise useful info.
I’ve done some more investigation… It appears that vue files are particularly slow to scan, however it’s considerably worse when they’re in multiple directories (standard web project). The interesting thing here is that it doesn’t matter for js or ts files, only vue.
If we remove all the vue files from the normal project structure and place them in a singular directory, the scanning is ~5x faster (we went from 25 minutes down to 5 for the same number of files).
So I’m currently trying to work around the issue by altering the file structure post build, but before scanning places. This appears to come with its own set of issues though, the scanner thinks they’re not part of the project and now ignores them. Any help would be appreciated.
Bit of an update, I think I’ve gone as far as I can with attempts at circumventing the issue. I was able to move the vue files to a single directory between the build and analysis stages. I then added them to the correct “FilesToAnalyze.txt” for the project.
This resulted in a large reduction in scan time for the same number of files (it looks like the scanner crawls the directories and checks against the list rather than going by the list in the first instance?).
However, there doesn’t appear to be a way to hack it into the report that gets uploaded, or I couldn’t spot anything. I’m guessing this is something to do with the path not matching the structure in the branch.