Team is fixing the issues in SonarQube for each scan, is there any possibility to create the bugs automatically in ADO with the Sonar issues ? here we would like to validate whether team has fixed the issues or not and while fixing any new issues rises for every scan in the azure pipeline ?
We just want to track the work in ADO automatically not a manual approach ? if there is any possibility please help the steps to perform.
Regards,
Mohan
Related
I'm using Azure DevOps for deployment activities (releases in yaml way)
From time to time I have to re-run stages if it fails,
The problem is that when I click on Show Previous Attempts nothing happens and I can't see Attempt #1
Is anybody facing the same? or any ideas how to fix it?
After investigation, this issue has been confirmed as a bug and reported to the product group. Currently a fix for this issue has been prepared and the status is pending release.
You can keep track of this issue in our Develop Community forum. We'll update you when it’s available.
The company I work on recently purchased SonarQube Enterprise to improve code quality throughout all repositories. I found out that there is a feature that enables SonarQube to comment automatically on PRs targeting a specific branch, and I successfully managed to try that out.
Thing is:
That configuration is not scalable: I would need to manually configure every repo to follow that rule
That configuration needs a build pipeline to be defined "old school" on Azure DevOps to work, and we are moving into Pipeline as Code, starting of course with CI (where this takes place)
Anyone managed to get the PR commenting working in that scenario? Or, at least, solving the #1 problem?
Cheers
You can use REST APIs to do whatever configuration you need to do across your repositories. Refer to the REST API documentation.
Shouldn't matter, although I haven't tested it. The SonarQube tasks aren't aware of whether the build source is YAML or visual designer/classic/JSON builds. The underlying tasks and job running architecture is the same. As long as the build is hooked up to a branch policy, it should still work.
I am using Azure DevOps pipelines releases to try to deploy a windows service on premise. Periodically, the windows copy files step will hang and try again every 30 seconds and output "The process cannot access the file because it is being used by another process" as it attempts to copy the build artifacts.
We've ruled out any kind of permission issue. We've tried all sorts of tools to see what might be locking these files up and they don't tell us much.
This has happened before in the past with some other projects I was also trying to release on premise. Sometimes, I am able to just wait an hour or two and redeploy successfully (not exactly a solution I'm satisfied with), but this one particular project, a windows service, seems to be experiencing the issue very, very frequently. Almost every time I try to deploy.
Has anyone else experienced this? Or any word from Microsoft on the issue?
Thanks in advance.
I experienced this issue while trying to create and deploy a release from an existing artifact. So I have a build pipeline on Azure Devops that generates artifacts to be used by the release pipeline. All I did was to make a commit that triggered the build pipeline which generated a new artifact and triggered the release and it worked fine.
It was the first time I experienced this and I had no clue on why it happened.
I'm going to be doing more research and share any thing I find helpful.
I am having difficulties with the last two projects I have created using gated check-ins in Azure DevOps.
The error I receive:
[Error]The shelveset [ommitted] could not be found for check-in
We are using an onpremises agent and the last two projects I have created get this error on the gated check-in. However, our older apps that have identical build pipelines seem to be working fine so I do not understand why this is happening.
Does anyone have any ideas?
I was able to reproduce the same issue on my on premise agent as well as hosted agents. After investigating it seems like the account conflicts cause this error, that the build agent trys to check in the shelvesets with build service account other than you own account.
The same issue has been submitted to Microsoft. You can vote it up and keep track on it here, or your can submit a new issue regarding this issue on the same site by clicking on "Report a problem".
I have a VSTS repo connect to SonarCloud for quality analysis.
I need unique issues source for my team.
When SonarCloud create issues in his system, I want create an equivalent issue in VSTS.
And, when the issue in VSTS closed by a commit, I want close SonarCloud issue.
Can you help ?
Same question with GitHub...
Thx
Although there are issues created during an analysis in SonarCloud, the result is passed. So it won't create bug work item for such builds in VSTS.
The SonarCloud extension itself can not achieve what you want, one workaround here is using SonarCloud api and VSTS REST API to implement your own solution.