Thursday, January 23, 2014

Jenkins Series 2 - How to Create my First Job in Jenkins

Before share how to use Jenkins to build complex pipelines and create trends or build, sharing how to create your 1st Job in it.Click on the New Job. It will open a New Window with different Options.

Create a New Job

In the New Window you will see screen like below add the name of Job you want to create.
Provide the Name of the Job
Once Name is given, as a next step choose Add a Build Step. This is the place where you define what steps your Jenkins Job should perform. You can pick Windows or Unix Shell based on where you want to execute your command or scripts. In my example I have taken Windows. There are various other options available which you can play around once comfortable with Jenkins and you really need them.

Choose the Shell Want for Build Step

Once Shell is available add command or your batch file, shell script or any other steps want to perform. I have given only ls -l command and saved it. This is the place which really gets executed within the Slave (we discuss in other blog) a kind of compute node where process intended to be executed. In this case as you do not have anything registered other than master, it will run on the same machine where Jenkins is deployed and will provide you listing of workspace directory. It is a folder where Jenkins by default perform activities. You can use custom workspace as well (we discuss in other blog).

Once you click on Save will leads to following Screen and provide you Build Now Options
Click on Build Now to execute above step
On sucessfull execution you will see the results.
 Can click on the Console Output to see details of the Logs. Since we haven;t selected specific framework or selected reporting you will see console log by default for the steps executed above as it opens a Shell or Command Prompt and execute the steps.

Console Output

Hope now you have created your 1st Job on the Jenkins and ready for an interesting journey. Will discuss in coming blogs on how can register slave from the command line, what infect slave is, how we can consolidate results and run different kind of frameworks. So Stay Tuned.

Disclaimer: The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions

Wednesday, January 22, 2014

Jenkins Series 1 - Create Trends for Existing Results - Using JUnit Publisher

After taking a long break on Non Information Server blogging thought of sharing my recent exposure to Dev Ops Model. 
Today I will share my experience how we can use Jenkins as a Dashboard to show trends of nightly build tests. You do not require to use Jenkins for executing these tests. Can simply use XML report files generated from your nightly build verification system  and produce these trends live instead of relying on Spread Sheets and their tabs.

Here are few steps need to use Jenkins to produce Trends on Dashboard when have test cases executed are based on JUnit framework or results produced are XML Reports adhering to JUnit Framework.

Step 1: Copy Report produced by your Build Verification Tests or Unit Tests into the Slave or machine where you want to run the process. You can even use Shared Folder for the same

Step 2: For Windows use Execute Windows Shell and for Unix use Shell

Step 3: With-in Windows or Unix see Image Below to copy the report file into workspace. Can use Custom workspace if do not want to copy these files. Can also use to write some script which can executed based on your build number can be supplied as Parameter. Below step can be used to copy any other files as well not required for reporting.
Copy XML Report Files to Workspace
Step 4: Use Publish JUnit Test Report to show these results on Jenkins dashboard for selected build. Jenkins plugin will parse the files and produce results on the dashboard.
Publish JUnit Test Result Reports to Jenkins Dashboard
Step 5: Save the Jenkins job

Step 6: Execute the Build with Build Now
Jenkins will process these XML files and produce a Trend Graph. Since it is only for 1 Build should get failure and success details. Repeat the process for different builds and can see trends like this below.
Chart showing Trends for different build on Dashboard

Now above trend you see shows red graph going upwards means have failure across builds reducing the confidence in the build. You can write the job once and can be triggered at different intervals or by external trigger. Can navigate the graph and see failures component wide. Will cover these details in Next Blogs on how to identify failures and see if any regressions or new failures and Fixed from previous build.

Disclaimer: The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions