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 (each map is a branch so that it can be built individually). The list of maps and the latest generated map for this area is automatically updated and available here

(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. The git-master branch hasn't been updated, the code in this branch should still be functional.

(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. No action is required from the dev.

(3) A dev wants to work on an experimental feature. This could be a brand new functionality, a rewrite of a core component ( e.g. project "high five" ) or even a branch related to a specific ticket in trac. 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.

git clone https://github.com/navit-gps/navit.git
git checkout trunk # The branch we will create needs to be based upon 'trunk'
git checkout -b [name_of_your_new_branch] # We now create our own branch

(4) The feature is now mature and is ready to be merged into the trunk. As we currently keep the SVN trunk as the main repository, 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

git merge trunk
git push

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

git diff 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, coverity code analysis and package build ( instead of a daily build as we have currently )

to rebuild a documented, publicly available workflow. Some of the scripts that are currently used for the SVN workflow have an unclear license and we can't publish them

to leverage 3-rd party services and ressources ( CircleCI provides 4 containers for free for FLOSS projects ). These services typically require the use of Github

OK, I've pushed my commits, where is my CI output?

Completion of a CI run will be announced on IRC. You can also check at [1] to see if your CI build has completed.