* a single task cannot exceed 2 hours. This is causing issue for maptool. As a workaround, we have split the world in different zones, and had to sub-divide Europe in even smaller parts.

* a single task cannot exceed 2 hours. This is causing issue for maptool. As a workaround, we have split the world in different zones, and had to sub-divide Europe in even smaller parts.

+

+

= Proposed SVN + GIT workflow =

+

This workflow should explain a few possible use cases:

+

+

[[File:Git_workflow.png]]

+

+

* (1) A dev commits to SVN. The code is automatically merged into git, in the trunk branch, which triggers a build on the CI server. In this example, the tests (or build) fails, the workflow ends here

+

* (2) A dev commits a fix for the previous problem in SVN. The code is automatically merged into git, in the trunk branch, which triggers a build on the CI server. The tests succeed, the code is automatically merged into the 'master' branch, packages are built and translations templates are uploaded to launchpad.

+

* (3) A dev wants to work on an experimental feature. He forks the git trunk in a branch for his feature. He can benefit from having the CI test, and if configured, build packages for his feature.

+

* (4) The feature is now mature and is ready to be merged into the trunk. As we currently keep the SVN trunk as the official source, we can't just merge the code into git trunk, which should only get updates from svn trunk. The correct way to merge the feature is:

+

** pull the latest code from git trunk to make sure that commits in svn trunk did not break the code in the branch, and merge that pull in the branch. This will trigger a CI test that will ensure the status of the branch

+

** export that feature as a patch ( a diff between the branch, and git trunk).

+

** patch svn trunk to merge the code. This will trigger another merge to git-trunk and a call to the CI workflow

+

+

== Why do we want this? ==

+

The whole point of this workflow is :

+

* to ensure that we have a branch, somewhere, where the code is tested, and which we should never break ( this is git-master here )

+

* to benefit from automated steps. Each commit in SVN should trigger a regression test and package build ( instead of a daily build as we have currently )

Revision as of 05:20, 8 April 2015

We evaluated a few different CI solutions and currently CircleCI seems to be the best option for what we want to do.

opensource project can get up to 4 concurrent builds, for free

it is easy to setup and fully automated

it allows us to build, test and store the build results easily

The only drawback is that it is based upon Github. We have setup an extra repository to do more tests.

Currently we can :

have automatic builds upon each commit in each branch of the repository

run automated routing tests using dbus, and capture a screenshot and gpx / geojson output of the result

build binary packages ready for use. It's currently working for Android, for example.

What is left to do ?

expand our set of test cases

build packages for more different platforms

figure out how to get svn sync'ed back automatically

Ressources available during a build

32x Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz

4GB of RAM

~ 550GB of disk space

Current limitations:

a single task cannot exceed 2 hours. This is causing issue for maptool. As a workaround, we have split the world in different zones, and had to sub-divide Europe in even smaller parts.

Proposed SVN + GIT workflow

This workflow should explain a few possible use cases:

(1) A dev commits to SVN. The code is automatically merged into git, in the trunk branch, which triggers a build on the CI server. In this example, the tests (or build) fails, the workflow ends here

(2) A dev commits a fix for the previous problem in SVN. The code is automatically merged into git, in the trunk branch, which triggers a build on the CI server. The tests succeed, the code is automatically merged into the 'master' branch, packages are built and translations templates are uploaded to launchpad.

(3) A dev wants to work on an experimental feature. He forks the git trunk in a branch for his feature. He can benefit from having the CI test, and if configured, build packages for his feature.

(4) The feature is now mature and is ready to be merged into the trunk. As we currently keep the SVN trunk as the official source, we can't just merge the code into git trunk, which should only get updates from svn trunk. The correct way to merge the feature is:

pull the latest code from git trunk to make sure that commits in svn trunk did not break the code in the branch, and merge that pull in the branch. This will trigger a CI test that will ensure the status of the branch

export that feature as a patch ( a diff between the branch, and git trunk).

patch svn trunk to merge the code. This will trigger another merge to git-trunk and a call to the CI workflow

Why do we want this?

The whole point of this workflow is :

to ensure that we have a branch, somewhere, where the code is tested, and which we should never break ( this is git-master here )

to benefit from automated steps. Each commit in SVN should trigger a regression test and package build ( instead of a daily build as we have currently )