We now have the ability to disable GitHub comments per-project, but would it be possible to have a setting where a comment is only posted when a project is actually changed? We have a monorepo with over a dozen projects and a comment is currently posted for every single project, even if no code in that project was changed. For example:
PS: It’d be also great if the same comment could be updated instead of removing the old one and adding a new one. This would help with the notification spam the current approach does.
Thanks for the feedback.
I’ve moved this to the Suggest New Features category since what you’re asking currently isn’t possible.
And I have some questions!
Out of curiosity, do you run (and do you intentionally run) a build for every sub-repo when you raise a pull request in your monorepo? I know with some fancy workarounds you can get GitHub to only run builds on the changed code (unfortunately only requiring certain checks based on this is difficult, if not impossible).
I suppose I’m mostly curious why you would run a build for every part of your repo regardless of what has changed, but not want SonarCloud analysis to run (or maybe you just don’t want the comment?)
Would you not find it odd to have information from today’s analysis in a comment from 12 days ago?
We have our custom logic that does this accurately, but even if you do it perfectly this is an issue. Take this example:
- Project A depends on Library B. These are separate SonarCloud projects.
- Someone changes Library B. This will run all checks for Library B and projects that depend on it.
- Project A’s analysis has no changes, but the full, lengthy SonarScanner analysis runs regardless.
This is how we do it for our own bots, for example:
This is actually very convenient because all the information is located a single comment in the beginning of the pull request. SonarCloud posts separate comments for each project and creates a new comment on every analysis, which gets mixed up with pull request comments from reviewers.