repository
list
docker
image
Buiild job for each repository
run even when previous tasks fail
docker
image
repository
list
docker image
ROS workspace
ROS workspace
ROS workspace
On Github
On Github
coverage reports
coverage report
Pipelines-to-PPA relation
Single MRS ROS build pipeline - dense view
Full test pipeline with coverage reporting - dense view
Single-repository build action - dense view
Single-repository test action - dense view
ROS1 -> ROS2 repository/branch relation
Release-candidate (with testing)
MRS Build pipeline types
Repositories/branches
Single build job
Branches of source repositories
Origin repositories
Artifact ininitialization
Artifact ininitialization
Pre-building dependencies for coverage report [optional]
Unstable
Build matrix determination
Stable
Test unstable
Test stable
Single test job
Gather coverage
Test matrix determination
Collect artifacts
Delete docker builder image
Dockerhub
Dockerhub
Dockerhub
Dockerhub
- package that have
coverage: truein the yaml - software is built with flags to export code coverage reports while running
- pre-building packages before testing allows recording coverage in package
Adespite not directly testing packageA - the whole workspace is built, tared and passed further to each of the testing jobs
- it is also passed to the final job that generates the coverage webpage (that needs source codes, therefore, passing the workspace)
Repository list determination
- packages that have
test: truein the yaml - order of testing does not matter
- [optional] clones the package into the pre-compiled workspace
- creates a new
catkin/colcon workspacewhen no is passed from the previous jobs - compiles the tests
- runs the tests using
rostest
/tmp/artifacts
Docker builder priming
- Adds MRS PPA depending on the "variant" of the build (unstable, stable, testing)
- calling
apt update - installation
mrs-uav-system-full - saved to Github's registry
LCOV - MRS UAV System - Test coverage report

test_pipeline.png
devel
release
release_andidate
ros2_devel
release_candidate
ros2_release
ctu-mrs/ppa-testing
ctu-mrs/ppa-stable
- gathers and postprocesses the individual coverage reports
- creates the webpage https://ctu-mrs.github.io/buildfarm/
- creates the badge (https://ctu-mrs.github.io/buildfarm/badge.svg) for the main page
ctu-mrs/ppa2-stable
ros2
CI Scripts
- contains
- scripts
- dockerfiles
- github actions
- ... for building a single repository within the MRS system
- contains files that are reused in the Buildfarm
Buildfarm
- contains
- scripts
- dockerfiles
- github actions
- ... for building MRS PPAs and testing MRS software
- when executed, clonse CI Scripts into
ci_scripts.
master
ctu-mrs/ppa2-unstable
ctu-mrs/ppa2-testing
ctu-mrs/ci_scripts (ros2)
ctu-mrs/ci_scripts (master)
WHY ALL THIS?
- To be able to install the system via apt-get
- To make sure the system is always tested and working
- To automatically and safely propagate new changes into the stable release
- To provide installation for AMD64 and ARM64 architectures
ctu-mrs/ppa-unstable
ctu-mrs/buildfarm
ctu-mrs/buildfarm2
Base docker image
- contains
ros-noetic-desktop-full - prebuiilt by hand
- versioned by date
Build job
- loads the Docker builder image from Github's Docker registry
- accesses the repository from the commit
- [optional] install git and gitman submodules
- Runs the Docker builder image:
- installs dependencies via
rosdep - determines build order of ROS packages within the repository
- for each ROS package:
- generates build using
bloom-generatefor each ROS package - builds
.debpackage - installs the
.debto satisfy dependencies later
- generates build using
- installs dependencies via
- outputs the following into the
/tmp/artifactsfolder for the later jobs- the new
.debpackages
- the new
Collect the artifacts
.debpackages are collected and commited to the PPA repository
Clean build images
- delete builder images older than 7 days
Base docker image
- contains
ros-noetic-desktop-full - prebuiilt by hand
- versioned by date
New commit pushed to master
Docker builder priming
- Adds MRS PPA depending on the "variant" of the build (unstable, stable, testing)
- installation of neccesary build tools
- calling
apt update - saved to Github's registry
Repository list
- yaml file in the buildfarm repository
Cotains for each repository
- name
- address
- CPU architectures
- branches for
- unstable
- release candidate
- relelase
- If it should be tested
- If it should be built for test coverage
Docker builder priming
- Adds MRS PPA depending on the "variant" of the build (unstable, stable, testing)
- installation of the whole MRS UAV System
- saved to Github's registry
Clean build images
- delete builder images older than 7 days
Test job
- loads the Docker builder image from Github's Docker registry
- accesses the repository from the commit
- [optional] install git and gitman submodules
- Runs the Docker builder image:
- installs dependencies via
rosdep - builds a workspace
- runs ROS tests
- installs dependencies via

single_test_pipeline.png
Base docker image
- contains
ros-<version>-desktop-full - prebuiilt by hand
- versioned by date
New commit pushed to devel / Pull request to master

single_package_pipeline.png
release branches
- runs nightly
- only the
release-candidatepipeline can merge torelease stable-PPAshould therefore always be internally consistent and tested
stable-PPA
testing-PPA
Merge release_candidate to release
release-candidate branches
Publish test coverage
- runs nightly
- only core MRS developers can merge to
release-candidate - runs tests after the build
- if tests succeed, then it merges
release-candidateintorelease
Initialize artifacts
Generate test matrix
Build packages for testing and coverage generation
test jobs
- mrs_lib
- mrs_uav_managers
- ..
- ..
unstable-PPA
Generate build matrix
Runs more than 1 hour of simulation BDD integration tests
test jobs
- mrs_lib
- mrs_uav_managers
- ..
- ..
Generate test matrix
Commit to PPA
test jobs
- mrs_lib
- mrs_uav_managers
- ..
- ..
master branches
- runs nightly
- all MRS developers can merge to
master - also direct pushes are built into the
unstable-PPA- therefore, can be broken at any time
- however, quick fixes can propagate fast and can be quickly installed using
apt-get

release_pipeline.png
Generate test matrix
.debpackages are collected and commited to the PPA repositoryrosdep.ymlis commited to the PPA
- delete builder images older than 7 days
Repository list
- yaml file in the buildfarm repository
Cotains for each repository
- name
- address
- CPU architectures
- branches for
- unstable
- release candidate
- relelase
- If it should be tested
- If it should be built for test coverage
Docker builder priming
- Adds MRS PPA depending on the "variant" of the build (unstable, stable, testing)
- installation of neccesary build tools
- calling
apt update - saved to Github's registry
build jobs
- mrs_msgs
- mrs_lib
- ..
- ..
- ..
Runs more than 1 hour of simulation BDD integration tests
Repository order determination
- python script
- clones all the repositories
- does topological ordering of repositories containing ROS packages
- for simplicity and minimizing edge cases treats all dependency types equally
- loads the Docker builder image from Github's Docker registry
- clones the repository
- [optional] install git and gitman submodules
- Runs the Docker builder image:
2. adds the passingrosdep.yamlfrom the artifacts
3. installs dependencies viarosdep
4. determines build order of ROS packages within the repository
5. for each ROS package:
1. determines if the package needs to be built (if the commit changed or if the based image changed or if its dependency was compiled (is incompiled.txt))
2. generates build usingbloom-generatefor each ROS package
3. builds.debpackage
4. installs the.debto satisfy dependencies later
5. adds the package to the passingrosdep.yaml
6. if compiled, ads the package name intocompiled.txt - installs the created
.debfiiles into the into the builder image and squashes the image - Pushes the updated Docker buiilder image into the Github's docker registry
- outputs the following into the
/tmp/artifactsfolder for the later jobs- the new
.debpackages - the passing
rosdep.yml - the passing
copiled.txt
- the new
Base docker image
- contains
ros-noetic-desktop-full - prebuiilt by hand
- versioned by date
/tmp/artifacts
- rosdep.yaml
- on-the-go updated list of built ROS packages
- later commited to the PPA
- compiled.txt
- keeps track of what was buiilt, used to determine if a package should be rebuild due to its dependencies being updated
- We have 3 pipeline types, two ROS and one non-ROS, each producing
*.debpackages into our PPAs. - Each pipeline is executed for AMD and ARM architectures .
- Each pipeline is executed for each PPA variant (Stable, Unstable, Testing)

pipelines.png
Thirdparty (ROS)
- link to the repository list
- Packages are not ours but we need to build them for some reason.
Nonbloom (non-ROS)
- link to the repository list
- Packages that can not be built using bloom-generate.
- The pipeline for these is different: the docker build executes a script from each repository (
.ci/build_package.sh) that is supposed to build the deb package. This procedure is different for each repository, so it is implemented within each package. - Specialities: PX4 is not compatible with bloom-generate, so the ROS package is build by
catkinand the build artifacts are extracted from acatkin workspace
MRS (ROS)
- link to the repository list
- Packages are either MRS-developed or are in some way dependent on packages from this pipeline (e.g., on mrs_lib or mrs_msgs)
Table Of Contents