Closed Hydragyrum closed 5 years ago
Here's what we get out of an EE api call: (only keys retained for brevity)
{
"plugins": [
{
"key": "datastage",
},
{
"key": "scmgit",
},
{
"key": "authgithub",
},
{
"key": "gitlab",
},
{
"key": "jacoco",
},
{
"key": "ldap",
},
{
"key": "license",
},
{
"key": "abap",
},
{
"key": "sonarapex",
},
{
"key": "csharp",
},
{
"key": "cpp",
},
{
"key": "cobol",
},
{
"key": "cssfamily",
},
{
"key": "flex",
},
{
"key": "go",
},
{
"key": "web",
},
{
"key": "javascript",
},
{
"key": "java",
},
{
"key": "kotlin",
},
{
"key": "php",
},
{
"key": "pli",
},
{
"key": "plsql",
},
{
"key": "python",
},
{
"key": "rpg",
},
{
"key": "ruby",
},
{
"key": "sonarscala",
},
{
"key": "swift",
},
{
"key": "typescript",
},
{
"key": "tsql",
},
{
"key": "vbnet",
},
{
"key": "vb",
},
{
"key": "xml",
},
{
"key": "scmsvn",
},
{
"key": "security",
},
{
"key": "securitycsharpfrontend",
},
{
"key": "securityjavafrontend",
},
{
"key": "securityphpfrontend",
}
]
}
A quick test on our installation reverting #227 solves the issue. This is not a permanent solution, and so detecting when we are in an edition that supports branches is the way to go.
some additional info, apparently this was changed in v7.2 https://docs.sonarqube.org/display/PLUG/Plugin+Version+Matrix
@gabrie-allaigre - Even we are facing a similar issue in our project. We are using SonarQube developer edition - version 7.7 and gitlab plugin version 4.1.0.
I have created a merge request for the same, please review and merge. https://github.com/gabrie-allaigre/sonar-gitlab-plugin/pull/236
The problem with that PR is that it may adversely affect community users, who don't have the branch plugin.
Personally, I forked and undid the changes so that it would work on our instance, but it's not a tenable solution. I talked to some of the SonarSource devs a couple weeks ago, and confirmed that there's no real way to detect which edition of sonarqube is being run without administrator level credentials.
I agree that this may adversely impact the community users but I feel that we should think of fixing the issue with the community edition in a cleaner way without checking for the branch plugin as that fix is breaking the developer and higher editions. That's the reason I think that we should go back to the previous state and then address the initial problem in a better way. We are using the developer edition and are very badly impacted by this issue.
I agree as we're also using the enterprise edition. The workaround for the community edition is to not use the branch.name option to begin with.
Ultimately, it's up to @gabrie-allaigre to decide.
The ideal solution would be to bake in support for Gitlab into Sonarqube like they did for Github
@Hydragyrum is there any tracking issue for that? Just mentioned it to them here with regard to sonarcloud https://community.sonarsource.com/t/merge-requests-support-for-gitlab/806/2
@LennyPenny I linked a gitlab issue in that discussion as well. For now I think we have to push Gitlab to work with Sonar on this.
https://gitlab.com/gitlab-org/gitlab-ce/issues/25238 for reference
@gabrie-allaigre Can you please merge this?
Ok, thanks
A change was recently added with #227 where the existence of the "branch" plugin is checked. (SonarFacade.java : 273)
It seems that on the Developer editions and higher, this plugin is not shown in the list of installed plugins (as it's not a plugin on these versions). As a result, the code never sets the proper branch when searching for issues, and thus all issues are brought down to Gitlab CI, failing the pipeline.
eg:
The quality gate passes, but because there are issues (unrelated to the branch in question), the pipeline fails.