PR quality gate not updating after renaming repo/project in Azure DevOps

Template for a good bug report, formatted with Markdown:

  • versions used (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarCloud scanner with MSBuild

  • error observed (wrap logs/code around triple quote ``` for proper formatting)
    We renamed the project we are using for source control in our Azure DevOps tenant, and as a result the Git repo associated with it was renamed. Since then, for the projects that were already created, the SonarCloud/quality gate flag isn’t being updated, and the “See the PR” link is pointing to an out-of-date URL. I have tried to remove the Azure DevOps config and PAT from the Pull Request settings in the affected projects, but that doesn’t seem to be helping. Do you have any suggestions?

  • steps to reproduce

  • potential workaround

P.S.: use the #bug:fault sub-category if you’re hitting a specific crash/error , or the #bug:fp sub-category for rules-related behaviour

We appear to have the same issue. We renamed a repo in ADO before ever running sonarqube on it. When we did run sonarqube, pull request decoration fails because it is trying to post to the old repo URL. Also the “See the PR” link is the old URL.

I tried deleting the project in sonarqube, but same issue. It appears this is an issue with ADO sending the wrong URL.

We were able to solve the issue by wiping the _work folder in our Azure DevOps build agent. Apparently the old URL was being cached there.

That’s a great idea. I’ll try that and report back findings.

Unfortunately that didn’t work for me. One thing I did notice was in the the new directory created, the .work#\sonarqube\out\sonar-project.properties file has the attribute sonar.pullrequest.vsts.repository that still has the old repository name. I don’t know if that setting is managed within SonarCloud itself.

Hi,

As long as you don’t save the pipeline with the new repo name, it will not be taken into account (that might be a bug from MS), can you test that and let me know ?

Thanks.

I’m not 100 percent following you, but it sounds like you’re saying I should edit the pipeline, ensure it says the new name of the repo, save it, and then create a PR that would trigger the pipeline? I’ll try that.

Yes.

I fact, i reproduced the issue. But as long as we are relying on variable that are provided by the Pipeline itself, there’s not much that we can do here.

OK, I went through each pipeline and forced a new version to be saved. I’ll review in the coming days to see if there is any effect. Thanks!

I had to explicitly change the branch from master to another branch, and then change it back to master, but after that, it’s now working. Thank you!