GBS Development Workflow

From Tizen Wiki
Jump to: navigation, search


This document introduce the basic development model of GBS.

Basic terminology

Development JIRA: Contains required features/bugs for the next version of GBS.

Release cycle: Generally, GBS would be released every month, but it's not definitive. Any hotfix release can be releaed any time.

Gerrit server: Where git source code is maintained

Jenkins Server: Special jenkins job works on for submit code to OBS for building

OBS Server: Final packages build server

Staging Repository: <Internal>/staging/tools/ repository

External Repository: Released external repository

Architecture of GBS

GBS (git-build-system) is a developer command line tool that supports Tizen package development. It's used to generate tarballs based on Git repositories, to do local buildings, and to submit code to OBS (Tizen's main build service).

Detailed archtecture refer to: Package-Dependency-of-GBS.rst

Source Code Maintain & Build

All components of GBS are maintained in git on `Gerrit` server, for each projects there're the following branches:

 - devel: Development branch
 - release-%{version}: Pre-release / Code freeze branch
 - master: latest stable branch

Submitted/Merged patches can be submitted to internal `OBS` directly by `Jenkins` job. For `GBS`, there're three OBS projects corresponding the three different branches, they are:

 - Tools:Devel: for building accepted/merged code in devel branch
 - Tools:Pre-release: for building accepted/merged code in release-* branch
 - Tools: For building accepted/merged code in master branch

Development workflow

In principle, all changes to code and components dependency relationship must be tracked in `JIRA` tickets


Native components for GBS system including gbs, depanneur and git-buildpackage. Developer should contribute code to these projects based on features/bugs request.

Basic workflow as follow:

1. Submit code to proper branch and project on Gerrit Server.

2. Automatic testing on Jenkins Server. Jenkins server maintained jobs to monitor changes of project and submit code to backend OBS for basic building/testing

3. Add cases. Tester should monitor these changes and add cases if needed. Based on different changes, different test cases list should be tested. Different scenario as follow:

  - New Case needed. Tester should read bug/feature description carefully, and discuss with developer if needed, write/test case finally. 
    New test case should pushed to `itest-cases-gbs` project for testing.
  - Exsiting case should be updated. Tester also need analysis feature/bug description, and update cases based on changes.
  In the testing stage, tester should take the leading role should communicate with developer actively to push development/testing work move on smothly.

4. Tester give verify +1 on gerrit changes

5. Developer/Tester give code review +1 on gerrit changes

6. Maintainer merge code to git tree.

Component updates

Component here means third party upstream packages required by GBS. There're two types of packages:

- Taken from upstream directly with out any private patches. The reason to introduce these packages is that these packages do not exist in official distro repositories. These packages are osc, createrepo, deltarpm and qemu-arm-static.

- Taken from upstream and with some special private patche for GBS. These packages including build, pristine-tar, librpm-tizen and libcrypt-ssleay-perl.

Basic principle of upgrade of these packages is keep them up to date with upstream version, which is also the opensource principle, so also apply to us. Cases for the pacakges without any private patches don't need follow upstream strictly, but for cases we have private patches, and official distro also contain these packages, these packages must be up to date with upstream version closely, at least the version of these packages should not be lower than distribution offical version.

Take `build`, the core builder of gbs, as an example, it's maintained by openSUSE, if new released openSUSE version contains a higer version of build than us, gbs installation will have some issue if user already installed an higher official `build` version. In this case, our `build` must be upgrade to version higher than version supportted in the new distribution.

Please refer to for details steps to upgrade packages.