We recently upgraded our SonarQube Server Enterprise Edition from v2025.2 to v2025.3.1 and encountered an issue related to hidden folders. Our SonarQube Server instance is deployed via Docker. In our team, we build CI/CD scripting automation within our GitHub repository, specifically in the .github folder, which contains mostly Python scripts.
Before the v2025.3.1 upgrade, we were able to manually include the .github/scripts directory in our defined scan sources. Since there is other code within our repository that is not in the .github/scripts folder, we would include both the root directory (./) and .github/scripts in our included sources during a SonarQube scan. This setup functioned as expected, scanning code in both the .github/scripts folder and the rest of the root directory.
Ex: sonar.sources=./,.github/scripts
However, after upgrading to v2025.3.1, we began to see the following error from SonarQube:
File <github-script-file> can not be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files.
I believe this issue is related to the change mentioned here. It seems that now, with dotfiles being analyzed for secrets, these files are included in the scan index.
While we are pleased that these files are being scanned for secrets, we would like to continue scanning code files in these directories. If I change the source to just sonar.sources=.github/scripts, it scans the code files in this directory as expected. However, we would like the ability to scan code files in this directory along with the rest of the files in the root directory. Currently, it appears this is not possible.
We would appreciate any guidance or solutions to enable scanning of both the .github/scripts directory and the root directory simultaneously without encountering the indexing error. Preferably we would not need include the .github/scripts in the sources and we could enable full dotfiles scanning as a setting.
In v2025.2, I can’t get python files directly in .github analyzed, but I can if they are in .github/scripts and I set sonar.sources as you mentioned
In v2025.3, even though .github is being indexed, I believe that SONAR-25064 means that now the Python analyzer must opt-in to analyzing files anywhere in a hidden directory
I’m not sure if there’s a workaround or a better plan moving forwards. I will ping the folks who made this change to get their thoughts.
Indeed, with the introduction of indexing hidden files in >v2025.3, your current definition of sources is not working anymore.
In your definition of sources you were able to bypass our previous (<=2025.2) detection of hidden file and “force” the indexing of the files in the scripts folder.
With >v2025.3 we’re additionally indexing hidden files, so the Indexer tries to add the files in the folder twice, for each defined source.
As @Colin already mentioned, analyzers need to opt in to analyze hidden files, so the analysis of python files is currently not triggered in this folder.
–
To go back to your old behavior, setting sonar.scanner.excludeHiddenFiles=true alongside sonar.sources=./,.github/scripts should do the trick.
With this, the Indexer will not visit the .github folder while traversing your first source (./), but will visit .github/scripts during traversing the second source.
Unfortunately this means that you will lose the secrets analysis on hidden files, that are not located in the .github/scripts folder.
At the moment, I don’t see a better solution to your problem that enables both universal indexing and secrets analysis of hidden files, and the analysis of the hidden python files.
–
Preferably we would not need include the .github/scripts in the sources and we could enable full dotfiles scanning as a setting.
At the moment this is not possible. I will discuss internally, how we can better support your use case in the future, either by changing the indexing or the analyzer behavior.
Please let me know if the setting worked to support you or if you have any clarification questions!
Thank you Colin and Jonas for the prompt and helpful reply on this issue! It appears using the setting sonar.scanner.excludeHiddenFiles=true does fix our issue.
Looking forward to hearing if there are improvements to this behavior.