One-Click Solution for Tizen Image Creation based on Jenkins Framework

Introduction

This document provides comprehensive information about GBS Jenkins jobs supported by GBS from the 0.21 revision, including the following:

  • GBS local full build
  • GBS local build with package list

The following aspects are covered:

  • Overview
  • Prerequisites
  • Deployment instructions
  • Specifications
  • Configuration data

Overview

GBS Jenkins jobs provide automation solution for small team to efficiently perform package building, image creation and build artifacts publishing.

Upon clicking several buttons on the job web UI, images will be created and synchronized to additional repo and image download servers, saving developers from the repeating manual work of building packages and creating image on their own development machines, thus enhancing the efficiency of team work.

Prerequisites

GBS Jenkins jobs run on Jenkins framework, which requires one Jenkins master and several slave builders. The number of slave builders depends on the scale of the development team, as well as the frequency of job triggering.

Specific to our situation, detailed requirements are as follows:

Note: The master and slave nodes are logical concept, thus can be set up in one machine.

  • One node for one Jenkins master
  • Multiple nodes for Jenkins builders
  • One individual machine for respective download servers

The download server needn't to be connected to Jenkins master, but rsync or SSH must be properly configured to make sure all slave builders can upload build artifacts to download servers.

Deployment Instructions

This section describes how to deploy the GBS Jenkins jobs.

Installing and Configuring Jenkins Master and Slave Builders

Jenkins master and slave builder must be prepared first.

For information about the systems supported by GBS Jenkins jobs, refer to Supported Distributions.

For information about installing Jenkins master and slave builder, refer to one of the following, as appropriate:

Additional configuration for Jenkins master:

  • Configure Markup Fromatter: This setting update is only required for Jenkins 1.553 and later version. There's some raw html data for gbs jenkins job and parameter descriptions, which need jenkins to support it. Detailed steps from main page of jenkins master: Manage Jenkins => Configure Global Security => Enable security => Markup Fromatter, select Raw HTML item.
  • Global Proxy: If proxy setting required, it's recommended to set them in Jenkins master, details page item is Manage Jenkins => Configure System => Global Properties => Environment variables to add proxies like: http_proxy, https_proxy, no_proxy, etc.

Additional configuration for Jenkins slave:

  • sudoer Setting: gbs jenkins scripts required sudo free operations for gbs build and image creation tasks, and jenkins job will run as jenkins user, which is created automatically while installing jenkins, so user need make jenkins user sudo free by setting /etc/sudoers, or add additinal sudo file at /etc/sudoers.d/.
  • tizen development env setup: Firstly, ensure ssh <alias_of_git_server> works well by following instructions in Setting up Development Environment; secondly, download and install the Repo tool used by GBS jenkins scripts to clone source code by following installing repo.

Deploying GBS Jenkins Jobs

Follow Installing development tools document to install additional Tizen Tools Repo from which gbs-jenkins-job (on Jenkins master) and gbs-jenkins-scripts (on all builder nodes) will be installed.

Take openSUSE 12.3 as an example, to deploy GBS Jenkins jobs, execute the following commands:

$ sudo zypper addrepo http://download.tizen.org/tools/latest-release/openSUSE_12.3/ tools
$ sudo zypper refresh
$ sudo zypper install gbs-jenkins-jobs    # for jenkins master
$ sudo zypper install gbs-jenkins-scripts  # for jenkins slave nodes

Jenkins master must be restarted to reload all GBS Jenkins jobs after installation. Upon successful reloading, the following two jobs will be ready for use:

  • GBS local full build
  • GBS local build with package list

Job Specifications

GBS Jenkins jobs consist of the following two components:

  • GBS local full build: designed for Tizen package building, image creation, and build artifacts publishing.
  • GBS local build with package list: designed for building part of the packages based on users’ customization.

Specifications of GBS local full build

This job is designed for Tizen package building, image creation and build artifacts publishing by using repo and GBS as basis. It can be reconfigured to run periodically or be manually triggered whenever needed.

With PUBLISH option enabled, build artifacts, including build reports, repos and images, will be synchronized to respective download servers.

Before using this job, it is highly recommended that Creating a Tizen Image from Scratch , which is the manual equivalent of this job, is read and well understood.

Supported options are shown below:

MANIFEST_URL

This option specifies the manifest URL, which will be recognized by the repo command, for example, in tizen:scm/manifest, scm/manifest is the manifest path in remote tizen.org Gerrit, whereas tizen is the alias set in ~/.ssh/config, an example of ~/.ssh/config is shown below:

Host tizen review.tizen.org
Hostname review.tizen.org
Port 29418
User <username>
#ProxyCommand connect -S <proxy>:<port> %h %p
MANIFEST_BRANCHES
This option specifies the manifest branch used for synchronizing code, this value will be passed to repo command directly.
PROFILE
This option specifies the profile used for building, currently, the valid values are IVI and Mobile
ARCH
This option specifies the arch to be built, currently the valid values are i586 and armv7l.
REMOTE_REPOS (optional)
This option specifies the remote repos from which packages are obtained during package building. Valid remote repos must contans tizen repo data, including buildata, images and repos in it, for example: http://download.tizen.org/releases/daily/tizen/ivi/ivi/tizen_20140305.14/
PARALEL_THREADS
This option specifies the number of builders GBS runs in parallel. Valid value is non-negative integer.
EXCLUDE_PACKAGES
This option specifies the packages that will be excluded during package building. This option also can be used to break dependency cycles. Multiple packages must be separated by comma(,)
BUILD_ARGS
This option specifies more GBS build options, which will be passed to gbs build command. Multiple options are supported, different options must be seperated by space, For more information about gbs build options, refer to gbs build usage.
PUBLISH
This option enables the publishing of build artifacts, including build reports, images and repos.
PUBLISH_URL
This option specifies the URL address to publish build artifacts. The format of PUBLISH_URL must be the same as rsync format, which can be a local path or remote URL like: user@hostname:/path/to/publish_dir.

Specifications of GBS local build with package list

This job is designed for building part of the packages based on users’ customization, that is , developers can specify a list of packages which just have been updated in remote repos, and check if the final image can work well with these changes of packages.

To use this job, one remote repo must be specified, from which the building packages required by GBS and the ks file required by MIC can be obtained.

An example of remote repo is shown below:

http://download.tizen.org/releases/daily/tizen/ivi/ivi/tizen_20140212.7/

Most of configuration options are same with GBS local full build, additional ones are as follows:

KS
This option specifies the ks file based on which MIC performs the image creation. Valid values are the ones contained in the specified remote repo. List of multiple ks files, in which the names are separated by spaces, is supported as well.
BUILD_RDEPS
This option enables the building with dependency, that is, packages that have dependent packages will be built in correct dependency order.
PACKAGE_LIST
This option specifies the package list in which packages to be built are listed per line. The format must be the full path in remote Gerrit.

For more information, refer to Jenkins job page.

Configuration Data

The two Jenkins jobs introduced above are only the basic ones, users can clone them and create additional jobs for other purposes. For example, GBS local full build can be cloned for daily testing of different profiles (IVI/Mobile/PC). For different new jobs, users can configure the default MANIFEST_BRANCHES and PROFILE.

More Advanced Configurations

  • Configure Build Triggers

    Jenkins jobs support configure build triggers, steps are as follows:

    1. Enter main page of specific GBS Jenkins jobs.
    2. Click Configure button in the upper left buttons area to display Configure page.
    3. Find the Build Triggers item, select and set the desired one.

    For example, select Build periodically and set the schedule value to enable periodically scheduled tasks. For help information, click the Help button on the corresponding item on the configure page.

  • Build Environment

    Jenkins jobs support downloading source code from Gerrit or Git server defined in MANIFEST_URL. During configuration, ensure SSH private key and settings work on the build slave node. An alternative way is as follows:

    Add credentials and install SSH agent Jenkins plugin, then add your credentials in build environment.

    GBS's output supports colorful information. To make Jenkins console colorful, install AnsiColor Jenkins plugin. This plugin adds Ansi escape sequences and color support.

  • Configure Build slave

    Jenkins jobs run at Jenkins master by default. Add a slave node and make it only run at slave node. Steps are as follows:

    1. Follow Jenkins document to add build nodes to Jenkins master, and remember the node label.
    2. Click Configure button of Jenkins job to enter configure page.
    3. Search Restrict where this project can be run item, then enter the label slave node on which GBS Jenkins jobs run.
    4. Click Save and Apply.
  • Set default value for each Jenkins Jobs

    GBS Jenkins Jobs need many parameters, so once Jenkins jobs have been installed successfully, it's recommended to set a default value for most of them to save users from repeating manual work of setting the job. If the job is set to run periodically, this configuration becomes mandatory.