Don't fail GitLab pipeline on QualityGate failure - optional property #637
Conversation
…ailed analysis Could be useful in the interim period, especially for the analysis using "-Dsonar.qualitygate.wait=true" with "allow_failure: true" in GitLab.
GitlabMergeRequestDecoratorTest migrated to JUnit Jupiter API
…gration to JUnit 5
Only properties starting with "sonar.analysis." are available from the analysis context: https://docs.sonarqube.org/latest/analysis/analysis-parameters/
|
Playing with the change on a local Sonar instance it turned out that only properties starting with Btw, |
| @@ -121,11 +123,15 @@ protected void submitPipelineStatus(GitlabClient gitlabClient, MergeRequest merg | |||
| Long pipelineId = analysis.getScannerProperty(PULLREQUEST_GITLAB_PIPELINE_ID) | |||
| .map(Long::parseLong) | |||
| .orElse(null); | |||
| boolean dontFailPipeline = analysis.getScannerProperty(PULLREQUEST_GITLAB_DONT_FAIL_PIPELINE) | |||
| .map(Boolean::parseBoolean) | |||
| .orElse(false); | |||
There was a problem hiding this comment.
This is a facility we don't really want: someone who has access to submit scans can decide whether the pipeline passes on a Quality Gate failure, rather than it being clear that a passing pipeline is because of clean code. In the companies I work with, the decision is made up-front as to what rules must be adhered to, and it is assumed that a pipeline is passing because those rules have been met. If we start allowing people who control the scanner to decide whether they can bypass Quality Checks then we'd effectively be breaking the safeguard that Sonarqube is providing in these scenarios.
This PR adds an extra property
com.github.mc1arke.sonarqube.plugin.branch.pullrequest.gitlab.dontFailPipeline(disabled by default) which if set to "true" do not fail GitLab pipeline on its status update.As explained in #137, it might be useful in the interim period and while given changes cannot be feasibly tested (and we don't want to have the merge option blocked).
To simplify testing, I added
junit-jupiter-paramsand migratedGitlabMergeRequestDecoratorTestto JUnit Jupiter. Nevertheless, if you don't like that change, it is in a separate commit and the implementation is done just in the first commit (I can remove the others, if requested).I'm not sure about the name. Any better proposal is welcome. It would be also useful to put it somewhere in README, I haven't found a good section for that :-/.
Feel free to write if anything here could be improved.
Closes #137.