I installed the TSLint plugin for sonarqube in my Jenkins server https://github.com/Pablissimo/SonarTsPlugin. But its not described the git page as to how to set the configuration properties and values. How to specify the source directory, how to ignore test directory are two main concerns. Can some one provide an example configuration property set with basic configurations that I can use in my Jenkins?
You can use a sonar-project.properties file for configuration. There are some example projects provided by SonarSource that might be helpful.
Here's a quick example of how you could set the source directory, test directory, and files to ignore:
sonar.sources=client-app/src
sonar.tests=client-app/test
sonar.exclusions=client-app/node_modules, client-app/lib
UPDATE:
The sample projects have moved here. There isn't a JavaScript example anymore, but the syntax would be the same for any language.
The documentation for parameters that can be set is currently located here:
https://docs.sonarqube.org/display/SONAR/Analysis+Parameters
Related
I'm setting up a new Jenkins master server and configuring it using the Jenkins Configuration as code (JCASC) plugin.
https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md
I've configured most plugins with JCASC, based on documentation and examples inside the project, but I can't find the syntax for configuring plugin 'Fortify Jenkins Plugin' version 18.10.
I need to set these properties:
URL of the remote Fortify server, authentication token (generated on the fortify server) and which template to use.
Can anyone assist with an example or syntax for the yml file used by the JCASC plugin for Fortify plugin?
I don't know if fortify-plugin is compatible with JCasC, it might be or it might need some modifications. That said, if it is compatible, then the configuration export should work for it.
So, spin up a Jenkins instance, install the plugin, configure whatever you want in the Jenkins UI and then go to the CasC page and use the configuration export. That should give you a JCasC file containing your setup.
Alternatively, you can try the JCasC Schema experimental feature. It's a JSON schema generated by Jenkins that you can use in your YAML editor for autocompletion. More information here.
we have just released an update of the Fortify plugin with support for JCasC. Keep in mind, versions of the plugin prior to v21.1.36 were unable to support it, we had to make changes to make it happen.
You can find official documentation on how to use our configuration elements here. There's one correction to the documentation, though. Our top level configuration element is called fortifyPlugin instead of fortify mentioned in the documentation. It is going to be corrected in the next documentation update.
Here's a sample configuration for your quick reference:
unclassified:
fortifyPlugin:
url: "https://qa-plg-ssc3.prgqa.hpecorp.net:8443/ssc"
token: "3ab8c774-0850-483b-8be6-2907722a81d8"
proxyConfig:
proxyUrl: "web-proxy.us.softwaregrp.net:8080"
projectTemplate: "Prioritized High Risk Issue Template"
connectTimeout: "10"
readTimeout: "20"
writeTimeout: "10"
breakdownPageSize: "50"
ctrlToken: "5176d380-26ac-430f-95d7-0a2272cf3297"
I've been asked to move some variable from a Groovy script out into a configuration file. I'm fine using something like :-
readFile('../xx-software.cfg').split('\n').each { fileName ->
sh "wget ${theURL}${fileName}"
}
However, even though I have added xx-software.cfg into the same directory as my Groovy script it does become available for use within that groovy script.
I hope this makes sense!?
How can I move my variables out into a config file to make it easier for the application support team to make future edits without changing the code?
There are a few approaches you could use.
Firstly, file format for the configuration and how to read the data into variables. You could use Java Properties format, YAML or JSON and these are all handled by the Pipeline Utility Steps plugin with steps here. You can read the file with these steps:
readProperties
readYaml
readJSON
Next problem, how to get the file available to your pipeline so it can be read from the workspace using these steps. Possibilities are:
In source control with your pipeline code. It can be fetched with the pipeline.
In a separate source control for configuration, your pipeline will need a step to fetch it.
Use the Jenkins Config File Provider plugin. It has a step to provide a config file managed in Jenkins.
Provide it as a Custom Tool zipped archive from a binary server like Artifactory. You can use custom tool definition pipeline steps to make this available to the pipeline.
The Config File Provider option might provide any easy way to have a file that can be updated, but there won't be any version control of it.
I have installed Jenkins, create a project and configure it.
I run into a problem, Jenkins do everithing great except documentation generating.
Could anyone point me where I have done mistake, and how fix it?
Thank you.
------------------------ New information ----------
Console output:
I have renamed doc to javadoc directory, but it isn't help.
Here is screenshot of javadoc directory contents in console, it is clear that Jenkins plugin didn't generate documentation, but why?
It sounds like you are expecting the Jenkins plugin to produce the documentation. The Jenkins plugin merely copies files from the job's workspace folder to the build's archive area and provides a link to it. If your build steps don't produce Javadoc, then Jenkins won't be able to archive and provide a link to it.
Does your pom file include the maven-javadoc-plugin?
Are your build steps invoking a goal that includes Javadoc generation?
For example, "mvn jar" would compile Java and build the jar but not build the javadocs. Clearly you have executed a goal that executes the tests and provides a code coverage report, but that does not trigger the Javadoc goals either. You would need to make sure your build steps include a javadoc goal - i.e., mvn javadoc:javadoc. The standard goals can be found here: https://maven.apache.org/plugins/maven-javadoc-plugin/plugin-info.html .
I have a multi module project set up for sonar analysis using way #2 from Analyzing with SonarQube Runner.
The only difference is that I dont use a global sonar-project.properties file.
The global properties are defined in jenkins in the sonar runner build step.
This works perfectly fine with Sonar Runner 2.3.
As soon as I switch from 2.3 to Sonar Runner 2.4 this fails with the error that the mandatory sonar.sources property is not defined.
I have tried setting it in my global properties to sonar.sources=src but then sonar can't analyze a module that doesn't use src as source folder.
It looks to me like Sonar Runner 2.4 doesn't use the module's sonar-project properties anymore.
Or is there a way to tell Sonar Runner 2.4 to use the module's sonar-project.properties file?
The two supported layout when using SQ Runner are:
put all properties of all modules in root sonar-project.properties file
put each module properties in its own sonar-project.properties in addition to the root sonar-project.properties
It is also possible to add properties via command line (this is what you do when you define properties in SQ Runner build step).
Your attempt to not have a root sonar-project.properties but having individual sonar-project.properties files in sub modules was not identified as a supported use case. So I'm not very surprised it is no more supported (it was likely a side effect).
See http://docs.sonarqube.org/display/SONAR/Analyzing+with+SonarQube+Runner#AnalyzingwithSonarQubeRunner-Multi-moduleProject
I would like to run Sonar plugin on Jenkins without any build process (my intent was to integrate Sonar analysis within Jenkins and take advantage of the subversion plugins and configurations we already had on there).
I do not want to run the build process since that would take up unnecessary time; I would only like to have a Jenkins job dedicated for Sonar analysis.
You can do that. You have to triggering the analysis with the SonarQube Runner.
Go to the Build section, click on Add build step and choose Invoke Standalone Sonar Analysis
Configure the SonarQube analysis. You can either point to an existing sonar-project.properties file or set the analysis properties directly in the Project properties field
When you analyse with SonarQube Runner , then you should give the following mandatory properties:
sonar.projectKey=my:project
sonar.projectName=My project
sonar.projectVersion=1.0
# Path to the parent source code directory.
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# Since SonarQube 4.2, this property is optional. If not set, SonarQube starts looking for source code
# from the directory containing the sonar-project.properties file.
sonar.sources=src
In this case you may miss some rule violations (like FindBugs), because .class files are not provided. You have to build the project manually and set the sonar.binaries property to your class files. If you never want to build the project, then you can use the SourceMeter plugin for SonarQube too. It only needs the source files, but can produce more metrics and issues if you needed.