<p>Any CI/CD plugin can ultimately be scripted.  However, using plugins gives you better centralized control.  </p>

<p><strong>Consider the following scenario</strong>: Your SonarQube server location has to move to a new location.  </p>

<p>If you are using a script like the example you provided above, you would need to manually update every script.  This process is error prone as you may miss a script or worse, type the wrong address.  Instead, if you are using a plugin you can update the server location once and be done.</p>

CC BY-SA 4.0
2019-07-15T14:44:07.690Z
If I move the server , the plug-in requires same amount of rework as with plug-in. For instance, pointing to new sonarqube-scanner location and all. Ya if I choose automatic installation then your answer is correct.
PDHide
CC BY-SA 4.0
2019-07-15T14:57:41.150Z
@PDHide: You are correct if you have one build pipeline.  But imagine how this will scale if you had 5, 15, 100 pipelines.  One global configuration can save a lot of time in this type of setup.
Wesley Rolnick
CC BY-SA 4.0
2019-07-15T14:37:28.273Z
2019-07-15T14:37:28.273Z
Wesley Rolnick
<p>On learning about integrating Sonarqube to CI/CD pipeline, I came across the Sonarqube Jenkins plugin which most of the online blogs recommends.</p>

<p>After configuring it, I realized that the working is the same as that of running the sonar-scanner through the command line using below command.</p>

<pre><code>sonar-scanner.bat -D"sonar.projectKey=test" -D"sonar.sources=." -D"sonar.host.url=http://localhost:9000" -D"sonar.login=erwerwerwerwer"
</code></pre>

<p><strong>Same is applicable for any tool, as most can be executed through command line.</strong></p>

<p>So I am confused about,</p>

<blockquote>
  <p>what's the advantage of using a plugin over just running the tools as
  windows batch command in Jenkins build step.?</p>
</blockquote>

CC BY-SA 4.0
2019-07-15T13:29:50.067Z
More details in its documentation (and if it fails answering your question, [edit] to explain why it doesn't answer): https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/
Tensibai
<jenkins><jenkins-plugins><windows><sonarqube>
What is the need of plugins in Jenkins (Sonarqube)
PDHide
# What is the need of plugins in Jenkins (Sonarqube)

(Asked by: username_0 on 2019-07-14)

On learning about integrating Sonarqube to CI/CD pipeline, I came across the Sonarqube Jenkins plugin which most of the online blogs recommends.
After configuring it, I realized that the working is the same as that of running the sonar-scanner through the command line using below command.
sonar-scanner.bat -D"sonar.projectKey=test" -D"sonar.sources=." -D"sonar.host.url=http://localhost:9000" -D"sonar.login=erwerwerwerwer"

Same is applicable for any tool, as most can be executed through command line.
So I am confused about,

what's the advantage of using a plugin over just running the tools as
  windows batch command in Jenkins build step.?

**Tags:** jenkins, jenkins-plugins, windows, sonarqube

> **Comments:**
> **username_1**: More details in its documentation (and if it fails answering your question, [edit] to explain why it doesn't answer): https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/  

---

## 1 answers

### Answer by username_2 on 2019-07-15. Score: 2 | Accepted answer

Any CI/CD plugin can ultimately be scripted. However, using plugins gives you better centralized control.

**Consider the following scenario**: Your SonarQube server location has to move to a new location.

If you are using a script like the example you provided above, you would need to manually update every script. This process is error prone as you may miss a script or worse, type the wrong address. Instead, if you are using a plugin you can update the server location once and be done.

> **Comments:**
> **username_0**: If I move the server , the plug-in requires same amount of rework as with plug-in. For instance, pointing to new sonarqube-scanner location and all. Ya if I choose automatic installation then your answer is correct.  
> **username_2**: @username_0: You are correct if you have one build pipeline.  But imagine how this will scale if you had 5, 15, 100 pipelines.  One global configuration can save a lot of time in this type of setup.  

---

