I'm interested is it possible using Jenkins+Performance plugin to run more than one .jmx (jMeter) files.
I'm using SVN repository where I keep my jMeter scripts. But problem is I can add only one jmx file to repo. I want add more than one, but Jenkins runs only first one.
I think you can use Ant to do this in Jenkins.
Note the "testplans" element in the following build.xml snippet:
<jmeter>
jmeterhome="c:\jakarta-jmeter-1.8.1"
resultlog="${basedir}/loadtests/JMeterResults.jtl">
<testplans dir="${basedir}/loadtests" includes="*.jmx"/>
</jmeter>
More info here: http://www.programmerplanet.org/projects/jmeter-ant-task/
Related
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'm trying to make a Jenkins job that only scans the test source files, so everything under /src/test/java (using Maven). I use the SonarQube Jenkins post-action for this.
When we used to configure Sonar in the pom file directly we could do this in a profile:
<sonar.sources>/src/test/java</sonar.sources>
<sonar.tests/>
That worked fine.
But in the Jenkins job I have to specify these as 'Additional properties' and I can't seem to specify an emtpy sonar.tests element. I tried -Dsonar.tests, -Dsonar.tests=,-Dsonar.tests="", nothing works. When this element is not empty Sonar will attempt to scan the test files twice and crash.
The post-build step is specifically and explicitly a Maven operation. Your problem comes from trying to use Maven to do something un-Mavenish; i.e. ignore the convention that files in the tests directory should be treated as tests.
Since you want to scan your tests as code, your best bet is to use the build step (which uses SonarQube Scanner) and set your scanner properties manually. That will make it easy to set your sources directory and to omit the tests directory.
I use a shell script to create/run doxygen doxyfile to document my code base
which works absolutely fine(Schedule runs and recursive scan code base also
works fine).
Now my requirement is to do the same job using Jenkins CI.
I added doxygen plug which generates documentation output and stores the result in Jenkin workspace.
My question, is there any another ways to run script and generate doxyfile in
Jenkins environment and also
How to create url link to display doxygen HTML output.
Have you seen the Jenkins DocLink plugin? This plugin makes it easy to put a link on your project page to documentation generated in a build.
The team I work for manages a large collection of technical documentation which is written in LaTeX. Currently all the documentation we have is manually built by the editors and then checked into a version control system.
Is there a possibility to build the LaTeX files on jenkins/hudson?
If you can build your LaTeX files from the command line, Jenkins can build it for you.
Just create a job with a "Execute shell" build step.
You've tagged this question with [ant], so if you're building your documentation using an Ant script, you can alternatively add an "Invoke Ant" build step which calls the appropriate target.
Depending on which build system you're using you can also use plugins e.g. for Maven or Gradle. You can have a look at https://github.com/reallyinsane/mathan-latex-maven-plugin where you can find a maven and a gradle plugin. You can use them with none or less configuration.
I am new to Jenkins and just started configuring it. This is what i have done till now:
Installed and configured Jenkins to display the home page. Added PMD plugin.
Set the HUDSON_HOME to a specific directory > C:\Work\Jenkins
Configured a test build to run a simple do-nothing ant script. It runs successfully
Written an independent pmdbuild.xml to run checks on a set of files in C:\myview (I am using clearcase). This xml also copies the output pmd_results.xml to the workspace directory in $HUDSON_HOME/[job-name]/workspace
Now I added the pmdbuild.xml as a step in my primary build. So my build has 2 steps:
a. Run a simple script, do-nothing.
b. Run pmdbuild.xml which generate pmd_results.xml and place it in $HUDSON_HOME/[job-name]/workspace (HARD-CODED as Jenkins PMD plugin expects the file there)
Jenkins picks up the pmd_results.xml automatically with the plugin and displays warnings and everything.
Now the problem:
If I click on a filename in the PMD results, it gives a filenotfound exception as it is looking for the source file in $HUDSON_HOME/[job-name]/workspace.
My java code files are placed in C:\myview (a clearcase snapshot view)
My question is, do I need all my code files to be present inside $HUDSON_HOME/[job-name]/workspace ?? Meaning can't I tell Jenkins to look for the PMD input files in C:\myview or any other directory instead of $HUDSON_HOME/[job-name]/workspace ??
Sorry for the extremely long description.
Jenkins expects that all the code is in the workspace. Usually Jenkins is used to check out a copy of the code into the workspace, and then runs all build steps on the Sources in the Workspace.
Might seem restraining at first, but it saves you a lot of trouble if you need to move Jenkins to another server, or create a slave instance.
So I would suggest you let Jenkins check out your code (there should be a clearcase plugin) into the workspace, and run the analysis on the checked out code.
If there are compelling reasons why your code has to stay where it is (C:\myview in your case) you can still set the workspace of your build to that directory (find this in the job configuration page, you need to click on the 'extended' button to see the option).