Closed axel3rd closed 4 years ago
Hello
Yes, Pull Request Analysis feature seems to be quite useful. I'm thinking of how can I recognize a PR though. Do you use TeamCity Pull Requests? I can try to get some data here.
Do you use TeamCity Pull Requests? I can try to get some data here.
Yes (of course, nice feature :heart_eyes:).
And you are right, if these data (PR feature) can be used, the mapping can be done more easiest than some build parameters.
Currently I can see for GitHub PR (EDITED 24/10: Update with last TW-61490 remark ; Pull Requests TeamCity plugin version 66559 at min).
SonarQube parameter | TeamCity parameter | Remark |
---|---|---|
sonar.pullrequest.key |
teamcity.pullRequest.number |
-- |
sonar.pullrequest.branch |
teamcity.pullRequest.title |
Used in SonarQube UI only |
sonar.pullrequest.base |
teamcity.pullRequest.target.branch |
|
sonar.pullrequest.provider |
To extract from vcsroot.url |
In discussion in TW-61490 |
sonar.pullrequest.github.repository |
vcsroot.url |
With an extract from complete SCM URL (before last \ , or .*github.*/(.*)/(.*) --> \1/\2 ) |
sonar.organization |
-- | Seems not used into SonarQube |
sonar.host.url |
Defined in plugin configuration, or require #70 |
I have never develop TeamCity plugins, but if there are some tips/docs entry point about Build Feature extension, I can try.
After reflexion, this build feature could perhaps extended to SonarQube Branch analysis, in addition of Pull Requests => Name SonarQube Branches & Pull Requests support
ie: managing sonar.branch.name
& sonar.branch.target
parameters.
NB: For SonarQube v7 series, a corner case is perhaps to manage due to SONAR-11155: set SONARQUBE_SCANNER_PARAMS
(containing Branch or PR parameters) only if project is exising on SonarQube endpoint, otherwise analysis will fail. The workaround would be to add this feature on build only after a first "classic" analysis.
FI: Community support question How to retrieve the "from" branch in a pull-request build ?, because after some tests, sonar.pullrequest.branch
is required.
because after some tests, sonar.pullrequest.branch is required.
According this SonarSource community forum post, sonar.pullrequest.branch
is only used to display branch in SonarQube/SonarCloud UI, there is no technical stuff based on it.
=> Until branch name or Pull request name can be retrieved from a TeamCity parameter, -Dsonar.pullrequest.branch="-"
can be a workaround.
Yes, it seems all important info could be retrieved before the build on server side from the pull request build feature. The only problem is to understand that the build is run on a pull request. Currently it's possible only by comparing the branch name against branch pattern in the pull request feature. I've asked the maintainer of the pull requests plugin to add some valuable data to the build parameters - hope it'll be done soon.
I'll try to find time for this next week. Or if you want you can try it yourself :) The class which adds parameters to the build is BuildStartContextProcessor
and you can use mvn package tc-sdk:start
to get running local TC server with built plugin inside.
Yes, it seems all important info could be retrieved before the build on server side from the pull request build feature.
As part of this problem I have opened the JetBrains support issue #2303046 : SonarQube GitHub Pull-Request integration - Multiple Git issues (JetBrains users access only).
In synthesis, the most mjor problem is that the "TeamCity Pull Request plugin" doesn't fetch the target/destination branch (i.e.: main
in most use cases) on a PR build ; and it is required by SonarQube Scanner to analyse files which have change vs the PR.
The only problem is to understand that the build is run on a pull request. Currently it's possible only by comparing the branch name against branch pattern in the pull request feature.
This could be done by checking if %teamcity.build.branch%
matches .*pull/([0-9]*).*
(at min for GitHub). I use that for other needs in MetaRunner (extracting PR key, this issue in this MetaRunner as workaround) and it works fine even if this is not the best solution.
Or if you want you can try it yourself :)
I will try to find time, but to be efficient in one week it will be hard ^^
See TW-61490 (Expose pull request related information in predefined build parameters 👍) for parameters name to use since v66536 of plugin.
To cover all providers on first implementation: TeamCity & SonarQube "Pull Request Analysis" integration - SONARQUBE_SCANNER_PARAMS details.
Workaround (For this incoming feature 🤞) : Use a TeamCity MetaRunner which manages this SONARQUBE_SCANNER_PARAMS
sysenv. See https://gist.github.com/axel3rd/0c2c8ccd2ba9832788d6387aed049dd2
Adding Pull Request Analysis (in GitHub Pull Request decoration for sample), configuring parameters could be a little tricky.
You have parameters:
sonar.pullrequest.key
/sonar.pullrequest.branch
/sonar.pullrequest.base
; to set on buildsonar.pullrequest.provider
/sonar.pullrequest.github.repository
; to configure in UIAll these parameters could be retrieved from TeamCity build parameters (at least for GitHub). If it can be provisionned by a TeamCity Build Feature, it would be great !!
This feature request is like the Using SonarCloud with Travis CI, which is very usefull.
Technically, it seems to work with the SONARQUBE_SCANNER_PARAMS system environment variable ; available since SonarQube Scanner API v2.7 (SCANNERAPI-159) & SonarQube Scanner for Maven v3.1 (MSONAR-147).
Content of this sysenv depending the build (Here GitHub+Travis classic & PR builds):