Tutorial #25 – Using Hudson Continuous integration tool

AlexQin

Invoking Build Steps

Now that we have seen all the basic steps to configure a build project, let us move ahead and add some more build steps. This section lets the user define his/her build with multiple build steps.

Each of the build steps has its own convention to define and invoke.

For instance, check out the ANT invocation below:

AlexQin

Configuring Post-build Actions

At times, it becomes necessary as well as vital to perform certain post build actions. Post build actions are nothing but some actions those are triggered once the build is executed. User is leveraged to trigger more than one post build action if he/she desires.

As we all know that the build execution statuses and reports are one of the most important artifacts or exit criteria for a Software development life cycle. Therefore, Hudson lets you publish the build execution report, generate documentations, generate executables/archives etc.

Test execution reports can be published and sent across to the stakeholders via Email. Results of this build can trigger the execution of another build.

Post build Actions are many, let us take a moment to discuss the most basic ones.

#1. Aggregate downstream test results – The setting lets the user aggregate the test execution results of this job and downstream jobs together to produce more impactful test results. All user needs to do is to provide the name of the downstream job. In case if the user doesn’t wish to provide any downstream job but still wishes to exploit the setting he can direct the Hudson to find all the downstream projects.

#2. Record fingerprints of files to track usage – The setting can be used by the user to track down where a particular file was used.

#3. Publish JUnit test result report – The setting allows the user to publish the JUnit test report by reading and understanding the custom report generated by JUnit. The JUnit test result report provides the user with a web interface to view the created reports. These reports can be sent over the mails to the stakeholders. To enable this option, all user is required to do is to provide the path to the custom report generated by JUnit.

#4. Archive the artifacts – This setting lets the user create artifacts which can be distributed for further use. The artifact can be produced after every successful build. These artifacts can directly be accessed by the user over the web interface. Artifacts can be release executables in the form of war files, jar files, zipped or tar folders.

#5. Publish Javadoc – This setting lets you publish the java doc to customers and users on the Hudson web interface provided your project generates the java doc. To enable this option, user is required to provide the location of the Java Doc against Javadoc directory.

If user checks mark the option “Retain Javadoc for each successful build”, the newly generated Javadoc would be saved in the specified folder. Thus, all the Javadocs corresponding to the successful build would be maintained.

#6. Build other jobs – The setting lets the user trigger the execution of other jobs once this job is executed. User can trigger execution of more than one job at the same time. The setting can be helpful to execute unit test and integration test scenarios. User can even set the option to build other jobs even if this job fails (unstable).

#7. Publish Cobertura Coverage Report – Cobertura is a java based testing tool which analyzes the code coverage of your project i.e. it assess the percentage of code covered by the tests. Thus the setting allows the user to generate a report with Code coverage analysis. The setting requires a few parameters to be provided before you can get a fully fledged testing report on code coverage. Take a note that this setting doesn’t come by default i.e. it requires a plugin to be installed (Which we did at the time of installation as it is generally a part of the suggested plugins).

(Click on image to enlarge)

#8. E-mail Notification – Email Notification is one of the most important post build action. The option lets the user send the build notification email to the stakeholders (developers, testers, product owners etc.) by configuring their email ids. Hudson can send the email when the build is unstable, successful, failed etc. User can also set E-mail Notification triggers. The notification email can be send to more than one recipient at the same time just by providing a white-space between their email ids. Refer the below screenshot to check how these settings can be provided.

(Click on image to enlarge)

Notes:

• User can anytime come back to this page and change the settings if required.
• User can view the information about each option within the help icon associated with it.
• User can add more post build actions with the help of plugins.
  
  

AlexQin

Conclusion:

In this tutorial, we made you acquainted with the concept of Continuous Integration. We also laid emphasis on its importance during a Software Development life cycle especially in a developer’s or tester’s life.

AlexQin

Next Tutorial #26: Moving ahead in the series, we would discuss about some advanced Selenium concepts that would directly or indirectly help in optimizing the Automation framework and brings more visibility to the users. Thus, in the next tutorial, we would discuss about the logging feature, its potential, debugging capabilities and much more.

AlexQin

Source

AlexQin

good job

AlexQin

good job