I’ve been learning Robot Framework recently and I wanted to see how it ties in with Jenkins so I can get a handle on Continuous Integration.
A while back I installed Robot Framework and the Selenium2Library on a Linux VM and found the Robot Framework reasonably easy to setup and use. After that I though it would be useful to see how much work is involved in setting up a Jenkins system. So I installed Jenkins on the same Linux machine using yum install jenkins, created a ‘Freestyle’ project and added a ‘Build’ step that called a Robot Framework test.
So far, so easy! The Robot Framework Selenium tests should start running (along with the browser window executing the tests).
At least according to the demos I had seen, that should have been enough to get it working but It didn’t work for me.
I was seeing
'Keyword 'Capture Page Screenshot' could not be run on failure: No browser is open'
| FAIL | WebDriverException: Message: The browser appears to have exited before we could connect. If you specified a log_file in the FirefoxBinary constructor, check it for details.
Lots of googling suggested it was something to do with running headless. Except the Linux VM in question isn’t running headless, but as far as Jenkins and/or Selenium were concerned, it was headless.
The options were;
- Run Jenkins from the console so that any browser sessions launched by Jenkins would run in the fore ground.
- Run Jenkins as a service. The theory is that the init scripts should be configured correctly to allow any launched browser sessions to open in the foreground. But I was already running this was because the yum install setup the init scripts for me.
- Run some virtual desktop software like vnc or Xvfb.
As I was already running as a service and the first option doesn’t seem robust, I figured I would try the last option.
Yum install Xvfb got me the software. I ran it from the console with
which starts an Xwindows virtual frame buffer which listens on ‘server number’ 1.
Next, I had to tell Jenkins that it should use ‘server number’ 1 as the display. I guess there are other places I could do this, but for the sake of expediency I added it to the console ‘Build’ step.
My ‘Build’ step then looked like this:
export DISPLAY=:1 robot /tmp/robot_nvbu/valid_login.robot
Where the export line tells Jenkins to send the display to ‘server number’ 1 and then executes the robot tests successfully.
If that works you can install the Jenkins Xvfb plugin to automatically manage the virtual frame buffer which means you don’t need to run it and you don’t need the export DISPLAY=:1 line in the build step. Apart from supplying Jenkins with the location of the xvfb executable and a name, the defaults (leave the fields blank) work fine and the documentation for the plugin is pretty good.
In reality the Jenkins server is not likely to be executing the browser tests. These would be farmed out to other servers and I read a few posts about running Jenkins slave servers in the foreground because of this issue, but the above seems reasonable.