[Tutorial] Continuous Integration Automated Build for your Pharo Application

reposted from jigyasagrover.wordpress.com/ci-automated-build-for-your-pharo-application

Hello Fellas !

This post aims to put forward the basics of Build Automation and also brief the steps required to put up a Pharo application on Continuous Integration, Inria which is a platform for Scheduled Automated Build.
For simplicity, Build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities including things like:
  • compiling computer source code into binary code
  • packaging binary code
  • running automated tests
  • deploying to production systems
  • creating documentation and/or release notes

Various types of automation are as:

  • On-Demand automation such as a user running a script at the command line
  • Scheduled automation such as a continuous integration server running a nightly build
  • Triggered automation such as a continuous integration server running a build on every commit to a version control system.
In recent years, build management tools have provided relief when it comes to automating the build process.
The dominant benefits of continuous integration include:
  • Improvement of product quality
  • Acceleration of compile and link processing
  • Elimination of redundant tasks
  • Minimization of ‘bad builds’
  • Have history of builds and releases in order to investigate issues
  • Save time and money – because of above listed reasons.

A build system should fulfill certain requirements.

Basic requirements:

  1. Frequent or overnight builds to catch problems early.
  2. Support for Source Code Dependency Management
  3. Incremental build processing
  4. Reporting that traces source to binary matching
  5. Build acceleration
  6. Extraction and reporting on build compile and link usage

Optional requirements:

  1. Generate release notes and other documentation such as help pages
  2. Build status reporting
  3. Test pass or fail reporting
  4. Summary of the features added/modified/deleted with each new build

Considering the above mentioned advantages of automated build, the below enlisted steps will help to put up your own Pharo application hosted on github on the CI server for continuous integration/scheduled build.
 1. Log on to Continuous Integration, Inria website (https://ci.inria.fr/).

Screenshot from 2015-08-08 15:53:49
2. Click on ‘Sign Up‘ at the top-right corner, enter the required details and register for CI.

Screenshot from 2015-08-08 15:54:02
3. From the ‘Dashboard‘ option located at the top most of the screen click on ‘Join an existing project‘ blue button as shown .

Screenshot from 2015-08-08 15:59:22
4. Search ‘pharo-contribution‘ in the enlisted public projects and click on ‘Join

5. On clicking the ‘Join‘ button, a message stating: “Request to join the project ‘pharo-contribution’ sent.” appears.

6. It might take a day or two for the request approval mail to deliver at your registered Email ID.

The E-Mail content is as follows:
        Your request to join pharo-contribution has been accepted
        Hi _ _ _,
        Your request to join the project pharo-contribution has been accepted !
        Regards,
        Support team.

7. Click on ‘My Account‘ option and under ‘My Projects‘ check the status of pharo-contribution project. It should state ‘member‘.

Screenshot from 2015-08-08 16:17:55
8. Now, visit the LINK: https://ci.inria.fr/pharo-contribution/job/JobTemplate/  to create a ‘New Job

Screenshot from 2015-08-08 16:21:06
9. Read all the steps mentioned carefully. After going through all the points, click on the ‘New Job‘ mentioned in point 2 on the Project Job Template web page.

10. Enter the ‘Project Name‘ in the ‘Item Name: ‘ box and choose ‘Copy from existing item‘ option and fill ‘JobTemplate

Screenshot from 2015-08-08 16:30:01
11. After clicking OK, You will be directed to your project configuration.

12. Fill in the description of the project in the desired box.

Screenshot from 2015-08-08 16:32:31
13. Fill int the configuration details of your project like:

* Maximum number of builds
*  Link to GitHub Project
*  Source Code Manager
* Build Triggers
*  Schedule of build (@hourly, @daily, @weekly, @fortnightly, @monthly, @yearly etc.)
*  Configuration Matrix (User Defined Axis: Name && Version Values- stable, development etc.)
* Build environment options
* Post-build actions
*  Report regressed tests

14. The main task is to carefully write the commands in the ‘Execute Shell
The default commands are as:

Screenshot from 2015-08-08 16:39:06
15. After saving and applying the changes, the application is all set for automated build.

16. Each build’s ‘Console Output‘ can be used to analyse the steps and highlight the weak areas of the project.
For instance: The below output is of a project whose stable version build was successful.

Screenshot from 2015-08-08 16:49:05

TIP: Keep a regular tab on the build results and analyze each line of the Console Output with utmost care.

Hope this post was able to help you start with the automation build process of Pharo Application.

Do like if it was worth a read !
Post queries/suggestions as comments 🙂 Looking forward to them.


UPCOMING: Next, I plan to share experience of putting up my Pharo application searchQuick on CI Inria for automated build. I intend to detail about the various configuration settings applied along with the Execute Shell commands utilized for a GitHub project 🙂


Introduction Accredits: Wikipedia 
Resources:  Build Automation and Continuous Integration .


Continue Reading

A low-cost laboratory for everyone: Sensor Plug-ins for ExpEYES to measure temperature, pressure, humidity, wind speed, acceleration, tilt angle and magnetic field

Working on ExpEYES in the last few months has been an amazing journey and I am gratful of the support of Mario Behling, Hong Phuc Dang and Andre Rebentisch at FOSSASIA. I had a lot of learning adventures with experimenting and exploring with new ideas to build sensor plug-ins for ExpEYES. There were some moments which were disappointing and there were some other moments which brought the joy of creating sensor plug-ins, add-on devices and GUI improvements for ExpEYES.

My GSoC Gallery of Sensors and Devices: Here are all the sensors I played with for PSLab..

The complete list of sensor plug-ins developed is available at http://gnovi.edublogs.org/2015/08/21/gsoc-2015-with-fossasia-list-of-sensor-plug-ins-developed-for-expeyes/

Sensor Plugins for ExpEYES

The aim of my project is to develop new Sensor Plug-ins for ExpEYES to measure a variety of parameters like temperature, pressure, humidity, wind speed, acceleration, tilt angle, magnetic field etc. and to provide low-cost open source laboratory equipment for students and citizien scientists all over the world.

We are enhancing the scope of ExpEYES for using it to perform several new experiments. Developing a low-cost stand alone data acquisition system that can be used for weather monitoring or environmental studies is another objective of our project.

I am happy to see that the things have taken good shape with additional gas sensors added which were not included in the initial plan and we have almost achieved all the objectives of the project, except for some difficulties in calibrating sensor outputs and documentation. This issue will be solved in a couple of days.

Experimenting with different sensors in my kitchen laboratory

I started exploring and experimenting with different sensors. After doing preliminary studies I procured analog and a few digital sensors for measuring weather parameters like temperature, relative humidity and barometric pressure. A few other sensors like low cost piezoelectric sensor, accelerometer ADXL-335, Hall effect magnetic sensor, Gyro-module etc were also added to my kitchen laboratory. We then decided to add gas sensors for detecting Carbon Monoxide, LPG and Methane.

With this development ExpEYES can now be used for pollution monitoring and also in safety systems in Physics/chemistry laboratory. The work on the low-cost Dust Sensor is under progress.

Challenges, Data Sheet, GUI programs

I had to spend a lot of time in getting the sensor components, studying their data sheets, soldering and setting them up with ExpEYES. And then little time in writing GUI Programs. I started working almost 8 to 10 hours every evening after college hours (sometimes whole night) and now things have taken good shape.

Thanks to my mentor at FOSSASIA for pushing me, sometimes with strict words. I could add many new sensor plug-ins to ExpEYES and now I will also be working on Light sensors so that the Pocket Science Lab can be used in optics. With these new sensor plug-ins one can replace many costly devices from Physics, Chemistry, Biology and also Geology Lab.

What’s next? My Plan for next steps

  • Calibration of sensor data

  • Prototyping stand-alone weather station

  • Pushing data to Loklak server

  • Work on [email protected] website

  • Fossasia Live Cd based on Lubuntu with ExpEYES and other educational softwares

  • Set-up Documentation for possible science experiments with the sensor plug-ins and low-cost, open source apparatus

Continue Reading

searchQuick Apprise: SEVEN #GoogleSummerOfCode #FOSSASIA

banner-gsoc2015.png.pagespeed.ce.1-XG35qq3R8SQJ5DGgL9

The intended searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.

header


After the chief tasks of search functionality and automated build were done with, the next undertaking included working on finer details and embellishments.

  • Embedding Jenkins automated build status icon in GitHub markdown file
  • Relative widget re-sizing by using ‘World extent x‘ and ‘World extent y‘ co-ordinates instead of hard coded co-ordinates
  • Modifying the Accordion Widget by addition of ‘Search Bar‘ at the top
  • Checking for duplicates in the ‘Browse Files‘ menu, thus reducing the CPU consumption
  • Equalizing the sizes of all the windows to bring uniformity
  • Addition of ‘Scroll Pane‘ in accordion search result display list
  • Multi-line search result display by extending the Expander Title Morph and use of new line character in labels (otherwise not supported by default)
  • Truncating file content to first n characters for neater look in Expander Title

Latest Screenshot of Accordion Widget:
Screenshot from 2015-08-18 18:38:06
UPCOMING:

  • Removal of OK & CANCEL buttons (present by default in Pluggable Dialog Window) from Accordion Widget
  • Implementing of Search via the result window as well
  • Relative re-sizing of background images (Image Morphs)

Continue Reading

Knitapps at the 7th Central American Free Software Congress ECSL 2015

On August, 9th, in San Pedro Sula, Honduras, I presented at the seventh Central American Free Software Congress a talk on Knitting Machines, Knitapps, Free Software and Free Manufacture.

DSCF5303

I had the opportunity to present on the main auditorium of Unitec, a private, technical university. The audience of the congress was compromised mostly of professionals and students from Central America. Local and National media also covered the event.

Continue Reading

Exception handler in KnitLib

An exception is an error that happens during the execution of a program. It is important to have exception handler in KnitLib to handle and deal with errors automatically. Many standard libraries define their own exceptions to report errors that may occur in functions they define.  Depending on the kind of error in knitlib (“communication error”, “pattern not found error”, etc.. ). The exception handler module in the knitlib can handle the exception and the knitlib can be continued afterwards with the previously saved data.

Define exceptions as classes

Exception can be defined as classes which do any other class can do, but are usually kept simple, often only offering a number of attributes that allow information about the error to be extracted by handlers for the exception. When creating a library like KnitLib which can raise several distinct errors, a common practice is to create a base class for exceptions and subclass that to create specific exception classes for different error conditions.

Part of the Exception Handler Module, catch exceptions raise from the library
Continue Reading

searchQuick Apprise: SIX #GoogleSummerOfCode #FOSSASIA

banner-gsoc2015.png.pagespeed.ce.1-XG35qq3R8SQJ5DGgL9

The intended searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.

header



The main task achieved was putting up the application up on Continuous Integration, Inria for automated build. It was indeed a beneficial idea as it helped me keep a check on the builds and work on issues.
Being a newbie, this work was cumbersome initially but with the help of my mentors and the #pharo community, I was able to accomplish it. To assist fellow Pharo-ers, I have compiled all the information regarding CI Automated Build for yout Pharo Application and published the same on my blog-spot. Kindly go through it for a complete understanding 🙂

Other tasks completed as of now include:

  • Putting up the project for automated build on https://ci.inria.fr/
  • Successful ‘stable’ and ‘development’ version builds
  • Accessing resource folder via MCGitHubRepository, Removal of manual download option
  • By default full screen system window open
  • Removing redundant code by creating open argument methods
  • Abolishment of hard-coded font family and font point size
  • Categorization of methods & classes
  • GUI Embellishment with background colors, borders etc.

Upcoming: 

  • Dynamic widget re-sizing
  • Multi-line search result title
  • Putting up Help and About sections
  • Removal of old configurations

Continue Reading

Importance of the test cases for the KnitLib

Having test cases is very important especially for a library like KnitLib because using test cases; we can clearly test particular fields.  In KnitLib, test cases show the information of how the KnitLib should be checked. Also test cases help for new contributors to understand about the KnitLib.

There are several test cases for the current KnitLib implementation such as tests on ayab communication, tests on ayab image, tests on command line interface, tests on KnitPat module and tests on knitting plugin.

For an example in ayab communication there are several important functions have been tested. Test on closing serial port communication, test on opening serial port with a baud rate of 115200 which ayab fits, tests on sending start message to the controller, tests on sending line of data via serial port and tests on reading line from serial communication.  Most of these tests have been done using mock tests. Mock is a python library to test in python.  Using mocks we can replace parts of our system with mock objects and have assertions about how they have been used. We can easily represent some complex objects without having to manually set up stubs as mock objects during a test.

It is very important to improve further test cases on the KnitLib because with the help of good test cases we can guarantee that the KnitLib’s features and functionalities should be working great.

Regards,

Shiluka.

Continue Reading

searchQuick Apprise: FIVE #GoogleSummerOfCode #FOSSASIA

banner-gsoc2015.png.pagespeed.ce.1-XG35qq3R8SQJ5DGgL9

The intended searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.

header



As the rudimentary structure of the application is sewn up, embellishment of GUI and rigorous testing are the major part of course of action.
On eMBee’s ( +Martin Bähr ) suggestion to build up an accordion widget to display the search results, various trials were conducted to design a similar one in Pharo.

The task of developing the accordion widget in Pharo was achieved using Expander Morphs. Looping through the search results array, a #newExpander: was added in each #newRow: of the modal built.

A challenging chore was to add a scroll-able content on the click of the desired search result expander. Sundry experiments with #newLabel: and #newText: in #newScrollPaneFor: {i.e. adding text model and labels in scroll pane} had no effect. Eventually, #newTextEditorFor: did the trick and the desired look was created.
Next on the cards is putting up sQuick for automated build on the CI Server, as suggested by +Sean DeNigris for its various advantages which include:
  • Improvement of product quality
  • Acceleration of compile and link processing
  • Elimination of redundant tasks
  • Minimization of ‘bad builds’
  • Have history of builds and releases in order to investigate issues
  • Save time and money – because of above listed reasons.
For simplicity, Build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities including things like:
  • compiling computer source code into binary code
  • packaging binary code
  • running automated tests
  • deploying to production systems
  • creating documentation and/or release notes
UPCOMING:
To achieve Build Automation for sQuick, I have already registered on CI and configured sQuick.
Next endeavor is to look into the red signal in the build evaluation.
 

Stay tuned for more….Post any queries, will be happy to help 🙂
Continue Reading

More about sTeam’s command line interface

This post will take you through some interesting work that I have been doing for my project under FOSSASIA. This project is being done under the google summer of code platform. I have been working on various code scripts as my project is all about improving the tools of the sTeam collaboration platform. But this particular script is a command line interface that I am thrilled to work on.

If you are not familiar with what sTeam is, you can look it up here, sTeam

Let me start with how sTeam originally works for any user. This picture will give you a clear view about it.

 

If you are new to the sTeam platform, this script will take you through the sTeam commands and the interface, also making sure, you have fun in the process. It lets the user play with sTeam and get to know more about how it works. One other interesting concept that we have tried to integrate here is that of MUDs(Multi user dungeons/dimensions). Some of you may already be familiar with the concept of MUDs( others, please look it up here MUD). We have tried to bring the MUD kind of experience to this sTeam interface (like I said, thrilling!).

I have seen people go through a lot of tutorials on git, and the commands(sometimes complex) through which it operates, and yet, people have difficulty learning it. What if it had a MUD type of interaction, which would just let you type “create file” “commit file” “get commit content” “upload file” “rename file” “goto repo”, etc. Wouldnt it be much easier that way? Well, sTeam is going through all the extensive tool development so that it can make a user-friendly interaction. Here are some screenshots of this interface,

 

steamshell2.png

steamshell3.png

steamshell_edit.png

 

This interface is under heavy development and plans to make sTeam more and more interesting for its users. If you have any questions on sTeam, please feel free to contact me, or join us on our daily scrum meetings on IRC (#steam-devel) or join #fossasia and ping us with a question.

If you are looking for a open source project and want to contribute to FOSSASIA, Please have a look at FOSSASIA labs.

Continue Reading

Dockerizing sTeam

I am currently working with sTeam collaboration platform as a GSoC dev under FOSSASIA umbrella.

sTeam has a lot of depencencies. A lot! One major issue faced by developers was version conflict between dependencies. Docker seemed to solve this issue. Docker is a great image distribution model for server templates. It uses btrfs (a copy-on-write filesystem) to keep track of filesystem diff’s which can be committed and collaborated on with other users (like git). It also has a central repository of disk images that allow you to easily run different operating systems and shares the host kernel.

In this post, I will explain the workflow of containerizing sTeam with Docker.

Prepend sudo

  • Install docker on host system, start & enable the docker.service
dnf install docker
systemctl start docker
systemctl enable docker
  • Pull a base image from docker hub

Note: It is upto you which image to use. I am using Ubuntu as base image.

docker pull ubuntu:latest
  • List the images to verify the pull
docker images

.. should display ubuntu latest xxxxxxxxxxxx x months ago x MB

  • Build your own image
docker build -t="dolftax/steam"
  • Lets run bash to install sTeam itself and its dependencies
docker run -t -i dolftax/steam /bin/bash
  • Install the packages and its dependencies.

In my case, sTeam server. Installation steps –https://github.com/societyserver/sTeam/wiki/Installation-steps#manual

  • Grab latest container ID. The first one would be the recently closed container.
docker ps -a
docker commit [container-id] dolftax/steam:v1

You should get a long hash as the success message

Note: v1 is a tag Don’t use latest tag. Don’t be tempted by it.
  • Create a docker hub account and login
docker login

.. which is self explanatory.

  • Push the image to docker hub (Before that, create a docker hub account anddocker login)
docker push dolftax/steam

Done!

.. after containerizing with docker, sTeam installation is as easy as

docker pull dolftax/steam:v1

Try containerizing your project and you would love it.

Continue Reading
Close Menu