I believe I am seeing this problem…
Multiple commits have been merged into our trunk, these commits were each under the threshold for the coverage to be checked in the branch and that was the case with trunk as well (for the new code threshold which is set to 4 days). Someone checked in a 3rd small commit which did not show a failure when it was scanned as a branch, but as soon as the merge was completed the trunk failed to pass the quality gate as now the number of lines was over the threshold. Is there anyway in sonarcloud to disable the ignore coverage if under x lines (I think is 19 lines).
I do not like the fact that a developer thinks their code passed, and then as soon it is merged it causes trunk to fail and halts other developers who need to merge to trunk.
Are you following the Clean as You Code methodology or do you have overall code conditions in your quality gate?
Maybe you can provide a little bit more information of your scenario (quality gate conditions at least)
We have only new code conditions and it is set at 4 days with a fixed percentage coverage required for the quality gate.
Just waiting a couple of days your code will probably pass your quality gate without doing anything.
Setting the new code period to 4 days seems to be very short, and the amount of new code will be always very small and you will be missing a lot of information after the weekend (two days!).
I suggest you to set at least one month (30 days) for the new code period if you cannot use “previous version”.
I don’t know how many developers are writing code for your project but I don’t think they will change or add a high number of lines in such a short period.
What do you think? Does it makes sense to you?
I am working on increasing the value to 30 (and thinking about it, that may reduce the possibility of the problem occuring as it would mean that there is a larger sample set with more large changes that adhere to the coverage requirements). When it is trunk based deployment you don’t want to wait a few days for the trunk to clear since we want to deploy at least once a day… My assumption was that it was not best practice to use previous version, if is fine for trunk based deployments with 2-3 changes per day that would solve the problem.