I am new to Robot Framework and I need to trigger my scripts from jenkins. Can someone give me a step by step guide for the same.
The ways Jenkins may access the test data and the ways to trigger Robot Framework scripts from Jenkins are numerous, so I am not sure how useful a step by step guide would be.
Start out simple - use a Execute shell or Execute Windows batch command build step. The script should read something like
python -m robot.run path/to/tests. The current directory is the root of the workspace.
Typically the tests would be put in the workspace by the Source Code Management configuration of the job.
As you add more and more jobs, you may want to have a common script to invoke Robot Framework, so that common configurations can be extracted out of individual jobs. If you want to always exclude certain tags (e.g. WIP), use a listener, or control where the output goes, using a common script is useful.
I highly recommend adding a post-Build step in the project for the Robot Framework plugin for Jenkins.
Related
I'm automating the following manual process with Jenkins:
Check out the trunk from svn
Build the code
Run tests
If the tests pass then tag the code and built artefacts
Steps 1-3 are working, but I need some help with tagging in step 4. There are some possible solutions that I've excluded:
The svn-tag plugin which has security issues and not developed
since 2015
The "tag this build" button which is a manual step and doesn't allow
me to select which files are tagged
Using svn command line tools on the slave, because I don't want to rely on them being install (and the same version as Jenkins), also I don't want to expose credentials to the build
Tools seem to be available for Git. Is there another way to do it for svn that I haven't thought of?
What about svn commandline?
Your could try to create a tag using shell :
svn copy http://svn/mywebsite/trunk http://svn/mywebsite/tags/2.2.1 -m "Release 2.2.1 - added new feature"
Source:
http://svnbook.red-bean.com/en/1.6/svn.branchmerge.tags.html
If it works, your step 4 could be a build step called : Execute Shell :
Just put your shell script in the text-area called command. You could use variables for your url, tag number, etc
Finally, you could create a jenkins plugin called svn command line tool to make life easier. Is not complex as many believe.
I wonder if it is possible to remove only one build (including artifacts) from job workspace.
I tried to "Delete Build" in Build History but all it does is remove build reference from Build History table. I know I can ssh to a server and delete files from the command line but I am looking for a way to do it from Jenkins web interface.
After installing Workspace Cleanup Plugin I am able to wipe out current workspace but I want to keep my other builds in the workspace.
In your Jenkins instance, to be able to have folder/per build - set flag "Use custom workspace" in your job's settings. Here is a brief help info from the setting description:
For each job on Jenkins, Jenkins allocates a unique "workspace directory."
This is the directory where the code is checked out and builds happen.
Normally you should let Jenkins allocate and clean up workspace directories,
but in several situations this is problematic, and in such case, this option
lets you specify the workspace location manually.
One such situation is where paths are hard-coded and the code needs to be
built on a specific location. While there's no doubt that such a build is
not ideal, this option allows you to get going in such a situation.
...
And your custom directory path would look like this:
workspace\$JOB_NAME\$BUILD_NUMBER ~> workspace\my-job-name\123
where $JOB_NAME will be "my-job-name" and $BUILD_NUMBER is the build number, eq. "123".
There is one nasty problem with this approach and this is why I wouldn't recommend to use it - Jenkins will not be able to reclaim disk space for outdated builds. You would have to handle cleanup of outdated builds manually and it is a lot of hassle.
Alternative approach, that gives you more control, tools and is able to keep disk space usage under control (without your supervision) is to use default workspace settings and archive your build output (files, original source code, libraries and etc.) as a post-build action. Very-very handy and gives you access to a whole bunch of great tools like, Copy Artifact Plugin or ArtifactDeployer Plugin in other jobs.
Hope that info helps you make a decision that fits your needs best.
I also use "General/Advanced/Use custom workspace" (as in #pabloduo's answer) on a Windows machine with something like:
C:\${JOB_NAME}\${BUILD_NUMBER}
Just wanted to add a solution for getting rid of the build job's workspaces.
I use Groovy Events Listener Plugin for this.
Using the plug-in's standard configuration I just use the following Groovy script:
if (event == Event.JOB_DELETED){
new File(env.WORKSPACE).deleteDir()
}
And now the custom workspace is deleted when the build job is deleted.
Just be aware that this would also delete non-custom workspaces (because the event is triggered for all jobs on your Jenkins server).
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 am looking at using Jenkins on Windows.
I currently have an ant script. It works pretty well. Except for instance, when the build breaks because of a syntax error, I can not see the error in the Jenkins console log.
So I am thinking may be ant is not the best tool for use on Windows.
What do most of you use for Jenkins on Windows?
If it is ant, how do you send the build output, VStudio, to the Jenkins console?
Thanks
Primarily I use Jenkins with maven projects, although you should see the ANT output in the online logs regardless.
What are you building? Are you building Java projects? Ant is what you use. If you are bulding a C project, you should use Make. If you're building a VisualStudio project, you should use msbuild. You use the build tool for your project. Jenkins will execute them without a problem.
Take a look at the build in question. On the left side of the screen, there's a Console output item. Click on that. Is there any output. No matter what tool you use, Jenkins captures the STDOUT and STDERR in that console output. If nothing else, you should see the exact commands Jenkins is executing to checkout and to build your project. Try executing those commands.
Still, you didn't give us much to go on. No idea what you're building or what you're doing with Ant. You didn't state any error, the console output, or even what the Jenkins error log is stating.
Jenkins does two things:
It watches your repository for changes.
Once it detects the changes, it executes the very commands you'd execute to build the project.
Jenkins doesn't care whether you use Ant, Maven, Make, or simply do a del /s/q. Jenkins will simply execute the commands you tell it to execute.
Addendum
It is c, c++, Java and InstallShield. I use ant to do file copy and move, call msdev.exe project. Some Javac calls, InstallShield command line builds..
Jenkins can execute multiple step builds in a single job. After you specify the build step, you can press the Add button to add another build step. There's no reason that all the build steps even have to be of the same type. Just select a "Freestyle" build, and use the right build tools for the job.
There's an optional MSBUILD plugin in Jenkins that should do your MS Build. This should give you the complete output from MSBuild, so you can see any errors.
After you do your MSBuild step, you can create a second build step to run an Ant task to build your InstallShield. After that, you could run another build step to do the copying you need either on the command line or through something like Ant (or Nant.
Whatever the output of the various tools is the output you'll get in the build console.
dev.cmd shows the output and I continue to use ant.
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).