Custom (Private) ROS-Projects in the Gitlab Infrastructure#

To use the provided ROS package infrastructure and keep the benefits of Docker support and continuous integration, it might be necessary to fork on or multiple of the provided projects. Note that this tutorial is only required when all git repositories reside within the git-st.inf.tu-dresden.de Gitlab instance; therefore, it is expected that the user has an account for Gitlab and furthermore has installed an SSH key.

Two use cases can be distinguished:

  1. Creation of a new package that uses the existing packages

  2. Modification of an existing package

In both cases, the panda_gazebo_workspace repository must be forked, as it contains both the Docker and the Gitlab CI support.

Forking the Workspace#

fork the workspace. This should be done using the fork button in the workspace web interface.

  • the resulting repository will be at https://git-st.inf.tu-dresden.de/<NAMESPACE>/panda_gazebo_workspace

  • <NAMESPACE> can be a user name or a group or subgroup

  • clone the previously forked repository

  • unlike described in the general tutorial, DO NOT CLONE RECURSIVELY (first, we have to adjust the submodule URLs)

  • git clone git@git-st.inf.tu-dresden.de<NAMESPACE>/panda_gazebo_workspace.git

Setting up the Submodules#

Submodules are defined in the .gitmodules file which must be modified, since the URLs in this file are relative to the location of the original repository. There are two cases for URLs:

  • A: Public Version. The public repository that is currently referenced should be used. This is the default case.

  • B: Fork. A fork of the submodule repository should be used. This is the case, if the submodule will be modified. In the following, the will be demonstrated using the sample_applications submodule.

  • All submodule URLs of type A must be adapted to the new location of the newly created fork.

    • The new URLs depend on the location of the fork. If the fork is in a subgroup, additional ../ must be added. If the fork is in a user namespace or a group, an entry in the file now looks like this:

    [submodule "src/franka_description"]
    path = src/franka_description
    url = ../../ceti/ros/franka_description.git

  • All submodule URLs of type B must also be adapted.

    • However, if they are in the same namespace as the workspace repository, they can remain the same. Assuming, we want to fork sample_applications, the new .gitmodules file looks like this:

    [submodule "src/franka_description"]
    path = src/franka_description
    url = ../../ceti/ros/franka_description.git
[submodule "src/panda_moveit_config"]
    path = src/panda_moveit_config
    url = ../../ceti/ros/panda_moveit_config.git
[submodule "src/panda_simulation"]
    path = src/panda_simulation
    url = ../../ceti/ros/panda_simulation.git
[submodule "src/sample_applications"]
    path = src/sample_applications
    url = ../sample_applications.git
[submodule "src/panda_teaching"]
    path = src/panda_teaching
    url = ../../ceti/ros/panda_teaching.git

  • After all submodules are fixed, the .submodules file can be committed.

  • Next, all submodules of category B (forked) must actually be forked (again, using the fork button in the web interface).

  • Finally, initialize the submodules.

    • git submodule update --init --recursive

    • now, the submodules should be filled with content

    • if the submodules you have cloned do not have a branch checked out, simply check out one (the default is master) cd src/sample_applications git checkout master

Adding a new ROS Package as a Git Submodule#

The following steps have to be done to integrate a new package into the workspace as a Git module and use the continuous integration of Gitlab.

  • Create a new repository in Gitlab.

    • Add some file to it (e.g., a README.md) to ensure the repository is not empty (otherwise, there is no master branch yet, which is required in the next step). This can easily be done in the web interface of Gitlab.

  • Add the new repository as a submodule

    • call the following command from the top directory of the repository: git submodule add -b master ../<REPONAME>.git src/<PACKAGENAME>

    • the package can be found in src/<PACKAGENAME> with the master branch checked out

  • Commit the changes in the repo

    • the CI should work fine now

  • Optionally create the new ROS package

    • e.g., by calling the following command from the top directory of the repository: catkin create pkg -p src <PACKAGENAME>

  • Optionally build the workspace catkin build