Template for a good new topic, formatted with Markdown:
ALM used:Azure DevOps
CI system used: Azure DevOps
Languages of the repository: C/C++
Hello,
I’ve got strange issue with passing Quality Gate status from SonarCloud to Azure DevOps once the Pull Request is created.
In details. I’ve got two repositories. Let’s say repo A and repo B. Repo A includes “infrastructure files” like yml pipeline files, properties files etc… Repo B includes ‘source code’ which have to be analyzed by SonarCloud. Now I would like to do the build verification for PRs from repo B by using pipelines (where it’s files are located in repo A). Everything works fine. The pipeline placed in repo A is executed and the SonarCloud analyze is doing correctly, but…
The issue is once I will add SonarCloud/quality gate status check to such PR. The status check has ‘Waiting’ all the time even if the quality gate for such PR is correctly calculated inside SonarCloud and such Quality gate appears in the Extension tab on appropriate pipeline build details.
The documentation says that this will work ONLY it the pipeline yml files and the source code will be placed in the same repo and I can confirm that making it this way it works and could be some workaround for now.
Although, I would like to avoid copying and paste bunch of yml files because currently I’ve got one infrastructure repo and over 40 (yes, fourty) repos like mentioned repo B where I would like to have some ‘generic’ solution. So my question is there any possibility to avoid copying and paste yml file to each ‘source code’ repos or there is no solution and the workaround remains?
What additional steps I did so far:
update/change Personal Access Token to the one which has got code read/write permissions
update/change ServiceConnection based on proper SonarCloud token inside Azure DevOps
Would you mind sharing why you’ve centralized all your pipeline scripts into a central repository instead of storing them with their relevant projects?
We’ve got one huge application with around 40 different libraries and modules. The application itself is included in this centralized ‘infrastructure’ repo and there it works perfectly.
Additionally, We would like to have some kind of detailed control on a related library and/or module repos from SonarCloud perspective cause they are developed in different programming languages, using different frameworks etc.by different teams.
All these modules are build by same pipelines with different parameters so in my opinion there is no reason to duplicate pipelines to each module/lib repo.
I don’t really follow your scenario, so all I can do is confirm that yes, you should probably move (rather than duplicate) your pipeline files into their relative projects.
I mean that I’ve got set of pipelines which are placed in ‘infrastructure’ repo and they are running build of module/lib from each of 40 repos.
So each repos from mentioned 40 uses the same set of pipelines from ‘infrastructure’ repo.
The workaround is that I have to copy and paste one set of pipeline files from ‘infrastructure’ repo to each module/lib repo. That’s the thing which I would like to avoid, but looks like it’s not possible for now… Right?
I’m getting the impression that you have a few standardized / generic pipelines that run against multiple projects.
Am I also right in thinking that any given project can/will be built multiple times with different pipelines from the infrastructure repo? And if so, why?
Unfortunately, yes, you would need to copy/move the pipelines into their respective projects.
Long story short… the app has got multiple modules and libs included and by using pipelines we can “produce” a couple of different application variants which depends on specific modules and libs… Only one, general variant of application uses all available modules and libs. Why this is done this way? Unfortunately, It isn’t question to me I suppose that the main reason was to avoid code duplication.
I suppose that the main reason was to avoid code duplication.